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日本語版への序 
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コンピュータやハイテク製品の需要が高く、供給がそれに追い付かない場合、生産者はマニュ 
アルの品質にはほとんど気を遣わないのが通例である。しかし競争が激化し、ハードウヱアや 
ソフトウヱアがだぶついてくると、生産者や販売者は、客の目をひき、気に入られる方法はな 
いかと躍起になる。コンピュータや他のハイテク製品の販売商戦が激しくなればなるほど、マ 
ニュアルの重要性は高くなる。 

本書がアメリカで出版されてから2年の間に、マニュアル作成の問題に対する意識は、劇的 
に向上してきた。マニュアルを“飾りもの”ぐらいに考えていた企業も、今では製品にとって 
必要不可欠な拡張部分、つまり周辺機器の1つといってもいいものとして、マニュアルを認識 
している。 

今日、大手ハードウヱアメーカーの多くは、“有用性テストのための研究室”を設置し、製品 
のみならず、マニュアルや他の印刷物の使いやすさに関してもテストを行なっている。 

しかしながら、マニュアル作成にどんなに関心を示し、情熱を傾けても、事態はいっこうに 
改善されていない。ほとんどのマニュアルは、相変わらず使いにくく、理解に苦しむものであ 
る。いまだにマニュアルおよびコンピュータ関連の出版物の大半が、必要な訓練をほとんど、 
あるいはまったく受けず、資質も充分でないような者によって書かれている。そして相变わら 
ず、信じがたい数のマニュアルが、自分の仕事が嫌いで嫌いで仕方がないという雇われ人によっ 
て書かれている状態である。 

その上、有用性をテストすることが、いつも有効な解決策であるとは限らない。本書が示す 
通り、マニュアルの第一稿が完成してしまってからでは、もっとも深刻な欠陥に対処するには 
遅すぎるのである。 

したがって、日本の読者への私のメッセージは単純である。よい マニュアルを 書くことがで 
きるのは、気を配るライターのみであるということだ。こうしたライターは、言葉に気を配る 
に違いない。図表や印刷に気を配るに違いない。そして、これがもっとも重要だが、彼らはマ 
ニュアルの読者の利益に気を配るに違いない。 

Edmond H. Weiss, Ph. D. 
April 1987 
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序：誰のために書かれたか 


本書は、マニュアル作成に何らかの形で関与するすべての人、すなわち企画、執筆、編集、 
出版などに携わる人はもとより、それらを管理する人をも含めたあらゆる人々に捧げるために 
書かれたものである。しかし、本書を一番必要としているのは、既存のマニュアルのほとんど 
に失望している人々（書いた本人も含む）であろう。本書は、そのような読み手にとつてマニュ 
アルがより適切で、なじみやすく、しかも読みやすいものになるように、一連の発想、原則、 
手法などを提供するものである。 


•マニュアルを考えるときがきた！ 

マニュアル 作成に ついて 真剣に考える時期がきているようだ。特に、 ューザー やオペレーター 
を対象としたソフトウェアの マニュアル 作成に関しては、それをテーマにした本が何冊か新し 
く 出版されたり、大学院の取得教科になっていたりする。 マニュアル 作成とは、コンピュータ 
科学はもちろん、技術訓練指導、グラフィック•アート、レトリックや作文法の伝統的な手法 
などさまざまな分野の技法.技術を結集したものと いう 意味から、明らかに1 つの 新しい専門 
分野であるといえるだろう。 

こうした機運が高まってきた原因は明らかだ。ここ1〇年ほどの間に、コンピュータ、ソフト 
ウェア製品、およびそれらの周辺機器の数は爆発的な増大を見せた。そしてほとんど例外なく、 
これらのシステム、機器、付属品などは、そのューザーやオーナーのために、何らかの文献を 
必要としてきた。 

このようなマニュアルの需要が量的にどれだけ増大したかはともかく、こうした状況が、マ 
ニュアルの対象となる読者層に大きな変化をもたらしたことは見逃せない事実である。かつて 
(ほんの10年ほど前だが）、 オペレーション •マニュアルの読者は、科学者、技術者、あるいは 
熟練者が主だった L しかしながら今日、コンピュータ•テクノロジーに関する訓練をほとんど、 
あるいはまったく受けていないビジネスマン、難解で込み入ったマニュアル （70 年代の半ばに 
は、これが常識だった！）を使いこなせる見込みのない事務員や作業員などが読者の主流なの 
である。 

いつの時代にも、よくできた、ほとんど完璧ともいえるマニュアルはあるにはあったが、そ 
れらは極めてまれで例外的な存在だった。かつて、技術者や高度な訓練を受けた専門要員が主 
に コンピュータを 操作していた時代には、使いやすく読みやすいマニュアルの必要性はあまり 
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序：誰のために書かれたか 


なかった。技術職に就いている人々は、マニュアルに難解さを求め、もっれた糸を解きほぐす 
ようにして、自分の方法を学び取っていくのが常だった。しかし今日では、不親切なマニュア 
ルと格闘しようというユーザーはまれである。実際、それをやろうとしてもできないのが現実 
なのである。 

•マニユアルの基本条件とは 

興味深いことに、よいマニュアルを書くための基本的な条件は、昔から変わっていない。マ 
ニュアルは、まず何よりも見たいときに いっでも 利用できなければ ならない。 また見直しやテ 
ストを重ねた結果として、正確かっ完璧な内容をもっようにならなければならない。そして、 
正しい言葉で書かれ、明白で読みやすい形に編集されなければならない。 

これらの大原則は普遍的なものだが、変化したものもある。それは、読む側の許容度と評価 
基準である。今日のユーザーは、たとえ専門家や技術者であれ、読みにくく分かりにくいマニ ュ 
アルに、あまり寛容ではなくなっている。昔のジョークにこういうのがある。「他になすべき手 
立てがなくなったら、マニュアルを読め。」もはや笑い話ではすまない。システムやソフトウェ 
アの製作者は、効果的なマニュアルを作ることが、市場競争に勝っためのキーポイントになる 
場合が多いということを、ようやく気付いたようである。コンピュータ業務の統轄者たちも、 
正確なマニュアルとガイドブックを備えることが、データ処理部門の生産性の飛躍的向上にっ 
ながるということを、ようやく理解し初めたようである。また、アプリケーション開発の初期 
の段階でユーザー用の文書を作成することが、その製品自体の質的向上に役立っということを、 
体験的に学び取っているシステム•アナリストもいるようである。 

しかし、 マニュアルの 質を改善したいと思う気持ちだけでは充分ではない。今日で さえ、 ほ 
とん どのマニュアルが、 何ら特別な訓練を受けていない人々 の 手によって書かれて いる。私の 
察するところ、代表的な ユーザー•マニュアルは 今でも、選ばれた ので 仕方なく、という シス 
テム •アナリスト や プログラマーの 手になる ものの ようである。だが、それ以外の マニュアル 
は、教育学や人文科学の分野から最近採用された才能溢れる人々の手によって書かれる ことが 
多いようだ。彼らの参加は コンピュータ 業界にとって極めて有益ではあるが、 ユーザー 用文書 
の作成技法に関する彼らの準備•研究はまだはなはだ不十分である。実際のところ、 マニュア 
ルの 製作•出版に長年かかわってきた エキスパートでさえ、 ’60年代以来の、 一つの 枠にすべて 
をあてはめようとする古い文書作成基準はもはや通用しなくなった、と嘆いているのである。 

籲本書の目指すもの 

したがって、この本の目指すところは、上述のすべてのグループの人々、そしてまたマニュ 
アルの企画、設計、作成に関する普遍的な原理を得たいと願っている人々の助けとなることで 
ある。本書には、この分野への新入生がやっかいな仕事にもひるまず立ち向かうことができる 
ような、さまざまなアイデアが盛り込まれているはずである。（実際彼らは、込み入った製品や 
システムを、経験のない、ときにはまったく専門外の読者に、うまく説明しなくてはならない 
のである。）また、経験豊かなテクニカルライターやエディター、文書作成の専門家にとっては、 
マニュアルをどのように改善したらよいかを分析し、またその改善に費用がいくらかかるかを 
頭の硬い関係者や上司に納得させるための1っのツール（道具）となるであろう。本書におい 
て、何よりも興味深くしかも実用的であろうと思われるとと、またそうあらんことを望むこと 
は一これが本書の中心テーマでもあるのだが一次のようなことである。 マニュ アルを作成して 
いく過程は、コンピュータの複雑なプログラムを開発していく過程と非常によく似ているので 
ある。 
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注：本書は、他と比較していえば一般的ではない書式と形式で書かれている。もっと明確にい 
うならば、多くの マニュアルが こうであって欲しいと思う書式と形式で書かれている。もちろ 
ん本書は、 マニュアルでは 「ない」。したがって、 このスタイルは 風変わりにも不適切にも見え 
るかもしれない。出版社と私は、そうしたリスクをあえて負うことにした。他の多くの場合と 
同様、マニュアル 作成においても、実例こそが最良の教師である、と信じているからである。 














測り知れない数の人々が、本書の概念形成に手を貸してくれた。ソフトウェアやマニュアル 
の多くのスペシャリストの作成した文書から得るところが大だった。そしてまた、私のクライ 
アントたちからも多くを学んだ。彼らは、何が問題なのかを私に教えてくれた。特に NCR 社の 
Stephen Bean、Kenneth Helms、Madeline Flynn、Michael Bartlett の各氏に深く 感謝しな 
ければならない。彼らは問いを投げかけてくれたのみならず、少なからぬ答えをも提示してく 
れた。 

本書の一部は、そのままの形ではないが、 Data Training 紙に一度掲載されたものである。 
第二章の一部分が1984年2月号に掲載された。これらは DATA TRAINING , Warren / Wein - 
garten 社の許可を得て使用している。 

DATA TRAINING , Warren / Weingarten , Inc ” 38 Chauncy St , Boston MA 02111, (617) 
542-0146. 

その他、企業のマニュアルからの抜粋は下記の人々に著作権使用の許可を得たので、謝意を 
表しておきたい。 


Jennie Balcom , Pioneer Data Systems , VAX MAIL User's Guide 
McDonnell Douglas Computer Systems Company , Introduction to REALITY 
Wharton Econometric Forecasting Associates , Inc ., Philadelphia , PA , Tables Documen ¬ 
tation : A reaching Introduction 

最後に、私が ISI Press 社の Maryanne Soper 氏に道をつけていただいた幸運な著者の 1 人 
であることを表明したい。 


凡例 


• 訳文中でのゴシック文字は、原文中でのゴシック文字に対応している。 

•訳文中で r 」囲みになっている文字は、原則として原文中のイタリック文字に対応してい 
るが、強調のために訳者が任意に追加したものもある。 

•訳文中で“”囲みになっている文字は、原則として原文中でも“ ”囲みになっている文 
字に対応しているが、強調のために訳者が任意に追力卩したものもある。 

•訳文中で （） 囲みになっている文字は、原則として原文中でも （） 囲みになっている文字に 
対応しているが、補足のために訳者が任意に追加したものもある。 

•訳文中での一は、原則として原文中の一に対応しているが、日本語の性質上、訳者が任意に 
省略、あるいは （） による置換えを行なっているものもある。 

•訳文中で•で始まっている小見出しは、原文にはなく、読みやすさを考慮して訳者が任意に 
追加したものである。 

•訳文中の下線は、原文にはなく、重要と思われる部分に訳者が任意にひいたものである。 

•原注は、原文にはなく、訳者からの著者への問合わせに対し、著者から送られてきた解答を 
訳出したものである。 

•訳注は、読者の便宜を考え、訳者が任意に付けたものである。 
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役割：マニュアルは何をするか 


1.1 ユーザーとは何か7マニュアルとは何か7 
1.2 マニュアルに関する3つの誤解 
1.3 優秀な人がなぜダメなマニュアルを書くのか 
1.4 新しい視点：デバイスとしてのマニュアル 
1.5 マニュアルの4つの役割 
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マニュアルを科学する 


1.1 ユーザーとは何か？マニュアルとは何か？ 


ユーザーとは、満足させなくてはならない存在である。さまざまな団体や個人が、独自の利 
益を追求するためにいくつかの目標を設定して、コンピュータ•テクノロジーを購入し、また 
それを開発している。たいていの場合、ユーザーは、設定した目標が必ず達成され、利益が得 
られるものと確信している 0 マニュアルは、 こうしたユーザーが、十二分な有用性と、思い通 
りの利益を獲得できるよう手助けする重要な情報ツールである。 


•ユーザーを満足させよ 

「ューザー」とは何かを定義することは、冒険的な試みである。慎重な言い方をするなら、 
「ューザー」とは、データ処理の単なる結果ではなく、それによってどのような成果が期待でき 
るのかということの方に、より多くの関心を示す存在なのだと定義することができるだろう。 

ューザーとは「満足」させなければならない存在だという場合、それは妥当な労力と費用を 
かければ、目的は必ず達成されると信じているのがューザーだという意味である。途中経過よ 
りも最終結果、単なる結果よりも成果、というわけである。つまり、ューザーにとっては、シ 
ステムがどのような「働き」をしているのかよりも、自分の個人的な利益に対して、システム 
がどのような「働き方」をしてくれるのかの方が重要なのである。 

確かにューザーは、 コンピュータの 内部の働きにも興味を示すようになるだろう。しかし、 
それは次のような基本的な概念をくつがえすものではない。すなわちューザーとは、自分の使 
用している特定のデバイスより大きな何ものかを、その内側ではなく、外側に望むものである 
ということだ 0 コンピュー タの世話にならずに、欲しいものを手に入れる経済的な方法がある 
としたら、彼らは迷わずそちらを選ぶだろう。 

なぜこの点を強調する必要があるかといえば、コンピュータの技術開発やそれに付随する文 
書作成に携わる人々の多くに、テクノロジーの開発_体を最終目標とみる傾向があるからであ 
る。また、そうした傾向の副産物として作成される マニュアルは、 ューザーが本当に望み、必 
要としているものを供給する手助けをする ツールで あるどころか、製品に関する使えない専門 
文書であることが非常に多いからである。 

•マニュアルはユーザーのツールで ある 

大型のシステムや製品の場合、下記のように個々の利害関係や役割分担が極度に細分化され 
ている組織では、組織全部がューザーであるということもしばしば起こってくる。すなわち、 
報告書のみに関心を払う役員たち、統轄管理に役立つ手立てを求めている各部門の管理者たち、 
システムの維持運用を任されている上級オペレーター、システムにデータを入力したり、動作 
結果を確認したりする初級オペレーターや事務員、メンテナンス要員やプログラマー、監査役 
や品質保証検査員などがューザーとして考えられる。 

繰り返していうが、これら多様なグループに共通していえることは、システムやプログラム 
の開発に携わる人間にとって、これらの人々はいずれも「満足」させなくてはならない存在で 
あるということだ。なぜなら、コンピュータに関連する商品を市場に供給している業者にとっ 
て、ューザーは「お得意様」であり、また自分の会社組織内でシステムやアプリケーションを 
開発している者にとって、ューザーは「自分の部署の上司」であるからだ。 

マニュアルは、 その読者がシステムから充分な利益を得ることができるよう手助けする ツー 
ルである（いや、そうでなければならない ）0 今さらいうまでもないが、 マニュアルは、 コン ピュー 
夕•テクノロジーの難解さやなじみにくさを解消してくれるものであり、次のような疑問に答 
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えてくれるものである。「次に何をしたらよいのか？」「これはどういう意味か？」 
「今、何が行なわれているのか？」「どうしてこれはうまくいかないのか？」 

図表1」 <マニュアルの主な機能〉 


機能 

例 

製品の使用開始を助ける 

•製品の働きとその効用を紹介する 

•製品の導入と使用準備をデモンストレーションする 

• 初歩的な操作と手順を指導する 
• エラーとバグについて警告する 

生産性アップと目標達成を助ける 

• 応用的な機能とその効用をデモンストレーションする 
• 生産性アップの方法を指導する 
. 作業の合理化を指導する 
• ユーザー独自の調整および修正を助ける 

問題解決を助ける 

• 起こり得る問題とその解決策を明小する 

• 専門家の助けを必要とする問題を明示する 
• ユーザーが開発者に依存しなくてすむようにする 


図表 1.1 が 示すように、 マニュアルは、ユーザー がその製品の使用を開始できるよう援助する 
だけでなく、次々に展開していく ユーザーの 関心に速やかに対応することを目的とし、最終的 
には ユーザーが 開発者に依存する度合いを最小化することを目指すベきである。この図表はま 
た、 マニュアル 内の記述の多くを、どこかもっと適当な場所に移した方がよいのではないかと 
いうこと も 示唆して いる。それは、 オンライン •ヘルプ 画面や参照画面、ビデオ.トレーニン 
グ•プログラム、 リファレンスカード、 ディスクに内蔵された チュートリアル •プログラムな 
どである。 

マニュアルのページが、バインダーに閉じられる代わりに画面上にあったとしても、よいマ 
ニュアルを書くためのこれらの基準はほとんど不変のものである。 
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1.2 マニュアルに関する3つの誤解 


マニュアルは、文学の一形態では「ない」0マニュアルは、「単なる」リファレンスではない0 
ユーザー用文書が「1冊」のマニュアルのみで構成されることはごくまれである。 


マニュァル作成に関するいくつかの誤った考え方に行く手を遮られると、どんなに高い理想 
を掲げていても、挫折することになるだろう。 

•マニュァルとは文学の一形態では「ない」 

マニュァルを書くということは、「英文学で最近学位を取りました」といったような、いわゆ 
る文章家を集めて行なうべき作業ではまったくない。もちろん、たとえ科学や技術を専門とす 
る企業でも、文学的素養を持ち、人間性豊かな者の協力によって利益を得ることはできる。確 
かに、マニュァルを作成するすべての企業がプロのライターあるいはエディターを少なくとも 
1人は必要としていることも事実である。そしてすベてのマニュァルは、言葉と文体を専門とす 
る人間によって、少なくとも一度はチェックされなければならないということも本当である。 
しかし、 言葉の技能とマニュァル作成の技能を混同してしまうことは愚かなことである。 

この種の誤解を解消せずにおくことは危険である。なぜなら、一歩間違うと、「技術者向けの 
参考文献を読みこなす力のない読者のためを考えれば、マニュァルは編集前の初期の段階にお 
いて簡潔で体裁のいいものに書き直されるべきであり、この書換えこそが技術文献とマニュァ 
ルとの唯一の大きな違いである」という短絡的な考えに陥ってしまうからである。 

実のところ、言葉を簡明で正確にするため、どんなに技術文献のすみずみまで手直しし、文 
体を一新しても、ューザーのニーズに応え切れるとは限らない。「簡潔さが足りない」「専門用 
語が、分かりやすい言葉に置き換えられていない」「文学的な、あるいは文体上の工夫が足りな 
い」などの声が上がったら、それは分析が不充分なために、誤った項目立てで誤った記述が誤っ 
た筋立てでなされているからにほかならない。 

•マニュァルは単なるリファレンス（参照資料）ではない 

リファレンスは、 マニュアルの 「一部分」をなすものである。そして、この一部分はシステ 
ムをどのように操作するかということを知った「後で」、利用するものである。 リファレンスと 
は、何を知らなければならないかを知った「後で」利用されるものを、索引形式で編纂したも 

のである。 

驚くにはあたらないが、プログラマーや開発者が「自分で作った」システムを自分で操作す 
るときには、このリファレンスがあれば充分である。彼らはシステムがどう動くか、何をして 
くれるか、どの機能を いつ 使ったらよいかをよく知っているからである。プログラマーや開発 
者がマニュァルを必要とするのは、彼らが忘れてしまったり、最初から記憶にとどめる気のな 
かった用語、規則、数値データなどをちょっと“調べる”ときだけである。同様に、あるクラ 
スのシステムを用いて、一般的な経験を積んできたューザーは、新しいシステムとどこが異な 
るのか調べるだけで、新システムを運用できるはずである。 

しかし、新参者のューザーはどうか。添付のリファレンスが完璧であれば、このューザーは 
システムを操作できるのだろうか。たとえば、「フォーマット」に関する説明が、リファレンス 
の 「 FORMAT 」 コマン ドの項目にしかなかったとしたら、どの デイ スクも フォーマット しなけ 
れば使えないということを初心者に伝えられるだろうか。 

よくあることだが、技術者にマニュァルを書かせると、「参照」資料になってしまう。たとえ 
“ューザーの知らなければならない事柄は、いちおうすべて網羅されている”としても、提示の 
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仕方によっては、情報をかえって不明瞭にしてしまい、結果的にマニュアルをほとんど役に立 
たないものにしてしまうということも事実である。 

•ユーザー用文書として1冊のマニュアルだけを作成することはまれである 

状況やシステムの性格次第では、必要な情報を1冊のマニュアルに詰め込むこともできる（た 
いてい驚異的な分量になる）が、その場合、マニュアルと他の情報伝達媒体を整理するライブ 
ラリが必要となるだろう。したがってマニュアル作成者は、1冊で充分であると確信できるとき 
以外は、マニュアルは2冊以上になるものと「想定」して構想を練るべきである。実際、マニュ 
アルは数冊のセットあるいはライブラリの一部として提供されることがほとんどであるため、 
ューザーが利用できるその他の関連資料の内容がどんなものかを知らずに、良質のマニュアル 
を設計または作成することは至難の業である。 

確かにプロンプト、メッセージ、ヘルプ画面などが自然言語に近い形で表示されるソフトウェ 
ア製品がどんどん供給されるようになったとはいうものの、相変わらず 1冊だけの百科事典的な 
ガィドブックでは、いわゆるューザーと呼ばれる読者層全体に貢献することは無理な話である。 

特に、ューザー層にバリエーションがある場合、またシステムやソフトウェアが多岐にわたる 
機能を持っている場合はそうである。 

重要なのはまさにこの最後の点である。今日では、多機能かつパワフルなソフトウヱアやシ 
ステムが登場してきたため、文字通り幾千もの使用方法をそこから引き出すことができる。ど 
のューザーも、この数多い使用方法の中で、ごく少数の使用法にしか関心を示さない。したがっ 
て、すべてのューザーに対して、簡潔な同じ内容のマニュアルを提供することが、意味のある 
ことなのかという疑問が生じるのである。 

もちろん、完璧な目次や索引や他の内容検索方法を設けて、マニュアルの質を向上させてい 
る企業は信頼を勝ち得ている。同様に、マニュアルの各ページを読みやすく整理している企業 
もよい評判を得ている。しかし、1冊の分厚いマニュアルにすべての情報を詰め込んでしまうこ 
とは、この中の情報を利用する際に、余計な負担をューザーに与えることになってしまう。1冊 
のマニュアルの分量が多くなり複雑になればなるほど、読者にはそれだけ余計なエネルギーと 
技能が必要になる。この「全ューザーのニーズに応える1冊のマニュアルを作成する」というコ 
ンセブトに私が反対する主な理由はここにある。つまり、有益な情報を得るためューザーが現 
在負わされている負担は、少なくとも部分的にはライターが負うべきものなのである。 

誤解しないで欲しい。すべての読者が使いやすいと認めるようなマニュアルを書くことがで 
きると主張しているのではない。また、ューザーやオペレーターの一部には、マニュアルがど 
のように書かれているかに関係なく、これを読もうとしない人々がいるという事実を見すごし 
ているわけでもない。私がいわんとしているのは、「使いやすい」マニュアルを作成する責任が、 
マニュアルの設計者と執筆者にあるのだという事実である。 
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1.3 優秀な人がなせタメなマニュアルを書くのか 


マニュアルを書くべきである多くの企業が、何も書いていない。書いていたとしても、ほと 
んどの場合充分ではなく、それを更新する努力を怠っている。そして、もっとも洗練された企 
業の手掛けたマニュアルでさえ、その大部分はまったく役に立たない。つまり、難解で、とっ 
つきにくく、不明確である。 


•優秀な企業は何をしているのか7 

品質が高く読みやすいマニュアルをコンスタントに作成する企業は増えている。そしてこれ 
らの企業よりも若干多い企業が、かなり高い割合で良質のマニュアルを作成している。しかし、 
この2つのグループを合わせても、ほんのひと握りにすぎない。 

これに対して、典型的なのはマニュアルなしというケースである。米国内を旅行してみて、 
いまだに驚かされるのは、コンピュータ会社、エンジニアリング関係の会社、ソフトウェア. 
コンサルタント会社、銀行、メーカーなどのどれほど多くが、自社のシステムやソフトウェア 
製品について、マニュアルも操作に関する手引書も持っていないかということである（それど 
ころ か、専門技術上の、あるいはシステムそのものに関する文書さえ持たない会社のなんと多 
いことか）。 

たび重なる要請にしぶしぶ腰を上げてマニュアルを書こうとする者がいたとしても、彼らの 
手でろくな結果が産み出されるはずはないのである。つまり、「急いで作って使えないマニュア 
ル」に始まって、「金をかけたのに使えないマニュアル」に至るまでが、彼らの仕事の成果なの 
である。 

なぜこうなってしまうのか。金銭自動出納機や、 CAD / CAM システムや、コンピュータから 
コピー機に指令を伝達するネットワークなどが設計でき、人材にも恵まれた優秀な会社が、分 
かりやすいマニュアルを作ることができないとはいったいどうしたことなのか。 

これの原因は主に次の2つである。1つは マニュアル作成を軽んじる傾向がある ということ、 

もう1つは マニュアル作成のやり方が分かっていない人間がいる ということである。 

コンピュータのマニュアルが出現するかなり以前から、いわゆる周辺装置に関する手引書や 
取扱い説明書の類はあった。この手の「作品」が主流である間はずっと、その大半が:つねに読 
みにくいものであった。読みにくい原因は何であったのか。それは、技術と生産に携わってい 
る人間の間に、こうした文献に時間とお金を費やすのはバカ気ていると考える風潮が昔からあ 
るからである。古いジョークに「説明書は、その日たまたま暇だったエンジニアのうちの誰か 
によって書かれる」というのがあるが、もはや笑い事ではすまされない。 

私の知り合いで書くのが好きな人間は皆無に等しい。私の知っているエンジニア、科学者、 
システム•アナリストのほとんどが書くことを嫌っている。書く作業の中で彼らがもっとも苦 
手とするのは、彼らよりも知識の少ない人々に、複雑な技術的概念を説明することである。 

マニュアル作成に ついて、 多くの企業の間に大差がないことは明白である。これらの企業は 
マニュアルを作成す るための 時間をまともに取らず、 たいてい 他に“もっと急を要する仕事” 
を抱えて いる 人々や、権限も力量も充分でない新入社員にマニュアル作成を任せて いる。 しか 
もマニュアルの執筆と製作に関し、デザイナーやテクニカルライターなどの協力者をまったく 
雇わず、できる限りの費用節約を行なって いる。 アメリカで書かれたマニュアルは たいていの 
場合、熟達した編集者のチヱックを受けずにユーザーに手渡される。 

マニュアル作成に関心を払う企業では、若干ながら事態は改善されてきている。それでもな 
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お、プロのテクニカルライターも含めて、マニュアル作成者を悩ませている一番の問題は、マ 
ニュアルの書き方に関する指針や指示が充分に得られないことである。マニュアルの執筆に関 
係する人々の大半は、手本となる既製のマニュアルを持っておらず、ほんのひと握りの人々し 
かモデルとして参照できる「出来のよいマニュアル」を持っていないのが現状である。実際、 
アメリカにおいては、新たに雇われたマニュアル作成者のほとんどが、マニュアルなど書いた 
こともないという管理職やボスの下で働いているのである。 

•マニュアル作成は誤解されている 

マニュアルを扱いやすく、読みやすくする技術についての研究は、およそ30年の歴史を有す 
るが、プロのテクニカルライターの多くも含めてほとんどの人が、この研究にまったく関心を 
示そうとしなかった。書く技術を確立することは、依然“芸術”の問題だと思われている。つ 
まり、やや意地の悪い言い方をすれば、霊感、直感、嗜好、天性の問題ということになる。マ 
ニュアルに関する議論のあまりにも多く （特に編集やデザインに関するもの）が、個人の好み 
に関する論争にすり換えられている。 

その結果マニュアルは、次の両極に分化することになる。一方には、マニュアル作成が嫌い 
で、できるだけ手間をかけず、作成されたマニュアルを評価するための基準などまったく無関 
心という専門技術者によって書かれるマニュアルがあり、他方には、自らの直感と文学的セン 
スを投入してマニュアル作成にあたるが、セォリーも作成されたマニュアルや請求すべき費用 
の正当性を測る評価基準も持たない職人的なテクニカルライターによって書かれるマニュアル 
がある。 

•マニュアル作成はエンジニアリングである 

本書の目的は、技術面の専門家とテクニカルライターおよびマニュアル作成に関係するすべ 
ての人々に、マニュアルの有用性（マニュアルの適切さ、読みやすさ、信頼性の高さ）という 
ものは、客観的に定義し評価することができるということを理解してもらうことであり、そし 
てさらにマニュアルの有用性を高めるためには、技術面の専門家とテクニカルライターの相互 
協力が必要であることを納得してもらうことである。アナリストや専門技術者が単独で仕事を 
したのでは、使いやすいマニュアルは作れない。これは、彼らが文章が下手だからというわけ 
ではない。アナリストや技術面の専門家は、ほかの職業の専門家に比べて、下手な文章しか書 
けないわけではない。むしろ、若干の例外はあるものの、彼らはあまりに多くを知りすぎてい 
るために、彼らよりも知識の少ない読者の前でとまどってしまうのである。また、協力者に恵 
まれているはずのテクニカルライターも、技術面のスタッフからの“情報収集’’をすべきであり 
ながら、それをしようとしないのである（やがては、マニュアルの読み手であるューザーが、 
マニュアル作成のプロセスに參入することもあろう）。 

よいマニュアルを作るには、マニュアル作りの考え方を根本的に変える必要がある。有効で 
使いものになるマニュアルを作るのは、「デザイン」の問題ではない（同様のことが、コンピュー 
夕のプログラムにもいえる）。それは「エンジニアリング」の問題である。キーポイントは、マ 
ニュアル自体を1つの「デバイス」と考えることである。 
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マニュアルを科学する 


1.4 新しい視点：デバイスとしてのマニュアル 


ライターが芸術家であり、マニュアルが芸術作品であると思われている限り、プロのライター 
はおろか、アナリストやエンジニアでさえ、使えるマニュアルを作る見込みはないであろう。 
要は、マニュアルを「デバイス」とみなすことである0こう考えることによって、マニュアル 
作成に関するさまざまな心構えが変わってくる。たとえば、マニュアルはどのように作成され 
るべきか、読者から何が求められているか、マニュアルを評価する上で何を基準とすべきか、 
マニュアルのコストをどのように評定すべきか • • •など。 


•マニュアルをデバイスとみなすと… 

マニュアル や他の情報製品が芸術作品とみなされるとしたら、それらを開発するための方法 
を変えることは、極めて難しいだろう。これとは反対に、本としての マニュアル、 あるいはビ 
デォテープや一連の画面などの視覚伝達媒体が、デバイス（ある特定の役割を果たす装置）と 
みなされるなら、 マニュアルの 「有用性」を向上させることができる。 

マニュアルとコンピュータのプログラムとの類似性を無視することはできない。 マニュアル 
は、プログラムがコンピュータのハードウェアに働きかけるのと同じやり方で、読者に働きか 

ける。 ただし、マニュアルの読者はハードウヱアよりも圧倒的にミスを犯しやすく、記憶の信 
頼性においてはるかに劣る。マニュアルは、解説を行なうとともにデータを読者に伝え、読者 
はこれらによってシステムを正確に、そして効率よく運用するわけである。 

マニュアルをデバイスとみなすといっても、マニュアルを他の名称で呼ぼうというのではな 
い。そうではなく、マニュアルをデパ'イスと考えることにより、多くのテクニカルライターと 
アナリストが、マニュアル作成の展望を変えざるを得ないということである。この変更を実現 
させるためには、マニュアル作成に関するわれわれの既成概念を見直し、そうした観念にとら 
われる姿勢を改める必要がある。 

•作成プロセスが変わる 

図表 1.4 にある通り、まず第一の変化は、マニュアル執筆の 「プロセス」 に対するわれわれの 
考え方に現われてくる。もしマニュアルを書くことが芸術活動であるならば、単語や文の構成 
や草稿作りの中に創造性がある ことにな り、芸術家を自認する執筆者は草稿を書き、それを推 


図表 1.4 <デバイスとしてのマニュアル〉 



“芸術作品”としてのマニュアル 

“デバイス’’としてのマニュアル 

驢要課題 

原稿の執筆 

設計のテストおよび練直し 

膀手順 

原稿執筆とその推敲 

分析.定義—モデノレ作成—テスト 

読者に対する評価 

自主的、知謀がある 

主体性に乏しい、ミスを犯しやすい 

根本的価値基準 

文体、 アピール カ、執筆者の嗜好 

仕様書との合致、使いやすさ 

発展的価値:基準 

美しさ、優美さ、“気品” 

メンテナンスのしやすさ（保守性)、信頼性 

出費の基準 

必要ならいやいや出費 

生産1生、有用性 

出費の方針 

可倉 g な限りの節糸勺 

利益と投資収益率 ( ROI ) の向上 
















役割：マニュアルは何をするか 
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敲する作業に多くの時間をさくことになる。これとは反対に、マニュアルがデバイスであるな 
ら、「エンジニアリング」の中に創造性があることになる。つまり、その創造性は、仕様書を書 
く、モデルを構築しそれをテストするといった、マニュアルの設計（あるいは原稿執筆）を実 
行する前になされるべきすべての作業の中にある。 

秦読者に対する見方が変わる 

また、「読者に対する評価」も変わってくる。芸術家を自認する執筆者は、読者を自主的で明 
敏な人々と見るが、これでは何かを発見してそれを正確に運用するという作業が読者の肩にか 
かってくる。一方、マニュアルがデバイスであるならば、読者は主体性を発揮する代わりに、 
マニュアルの企画.設計を信頼することで、上述の負担をマニュアル作成者に肩代わりさせる 
ことができる。後に詳しく述べるが、このように読者をみるなら、ライターは、ソフトウェア 
が ハー ドウヱアを コントロールす るのと同じように、読者の意思を コントロールす ることがで 
きるのである。 

♦価値基準が変わる 

マニュアルの「根本的な価値基準」もおのずと変わってくる。マニュアルが芸術作品である 
ならば、文体とアピールカが執筆の基準となる。すなわち、書いた本人には分かるが、他の人 
人には理解しにくい「精妙さ」とか「巧妙さ」といった感覚的な問題となる。マニュアルがデ 
バイスならば、マニュアルが仕様書と合致しているかどうか、マニュアルがその企画•設計段 
階において定義付けられた役割をきちんと果たしているかどうかということが、基本的な価値 
基準となる。 

マニュアルの価値を判断する上での「発展的な価値基準」も当然変わってくる。芸術家を自 
認するライターにとって、よいマニュアルとは、美しさ、優美さ、軽妙さ、“気品”を持つもの 
である。一方、マニュアルがデバイスならば、エンジニアリングの立場から見たものが、価値 
基準となる。つまり、保守性（マニュアルの更新やバージョンアップがどれだけ楽にできるか） 
と信頼性（マニュアル通りやってうまくいくか“否か”）の問題となる。 

•コスト評定が変わる 

そして最後に、マニュアル作成に関する「コスト評定」も大きく変わる。芸術家を_認する 
ライターにとって最も骨の折れる仕事は、マニュアル作成にかかる経費が妥当であるかどうか 
を判断することである。たいていの場合、彼らは「少なくともある種のマニュアル作成は、業 
務上必要不可欠なものである」という具合いに管理側を説き伏せる以外には、マニュアル作成 
の プロセス、 および出来上がったマニュアルにかかったコストの妥当性に関して説得する術を 
持たない。マニュアルの“気品”や“文体”にしてもいつも説得力を発揮するわけではない。 
これに対して、デバイスとして作成されたマニュアルに対する評価基準は、マニュアルがさま 
ざまな経費の節約に役立つ、すなわち利益を産み出すか否かということにある。マニュアルを 
デバイスととらえているマニュアル作成者は、費用の妥当性を主張することに、ほとんど不安 
をおぼえない。なぜなら、デバイスとは、例外なくそれにかかった費用よりも多くのものを見 
返りとしてもたらしてくれるからである。 
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マニュアルを科学する 


1.5 マニュアルの4つの役割 


今までの習慣でいえば、マニュアルは2つの大きなカテゴリーに分けられる。つまり、「イン 
ストラクション（手引書など)」と「リファレンス（参照資料など)」である0しかしこれまで 
の実務経験を踏まえれば、インストラクションはさらに2つのサブカテゴリーに分割されるべき 
であろう0つまり、「チュートリアル（初心者向け教育用）」と「デモンストレーション（上級 
者向け実演用）」である0さらに考察を加えるならば、第四のカテゴリーが現われてくる0すな 
わち、「動機付け」である0これは、ユーザーがあえてやりたがらないことを、やるように仕向 
ける部分である。 


•マニュアルの2つの役割 

よくできたマニュアルの基本単位やモジュールは、厳密にある1つの機能を果たすよう定義さ 
れている。しかし、ここでいう機能とは何か。マニュアルとは何をするものなのか。これまで 
のマニュアルは、以下の2つの方法でューザーの手助けを行なうものとされてきた。 

•インストラクション（手引書）としての機能：システムや製品がどのように作動するか、 
あるいは操作されるかについて教えるもの。 

• リファレンス（参照資料）としての機能：ューザーの記憶には残っていないと思われるキー 
定義、用例、コード番号などを提示するもの。 

•インストラクシヨンはさらに2つに分けられる 

しかし、システムやューザーの領域での変化にともない、マニュアルもさらに明確に細分化 
する必要があるように思われる。コンサルタントとしての経験から、私は「インストラクショ 
ン（手引書など）」を1つのカテゴリーとして扱うのは、あまりに大ざっぱすぎると結論付けて 
いる。そこで、インストラクションを「チュートリアル（初心者向け教育用）」と「デモンスト 
レーション（上級者向け実演用）」に分割したらどうか、というのが私の提案である。チュート 
リアルとは、初心者ューザーを教育し、正しい方向に導く教材のことである。また、デモンス 
トレーションとは、一定の水準に達している読者や、経験を積んだ読者に対し、ある仕事を行 
なうプロセス、あるいは作業内容を教える教材である。 

「チュートリアル」は、もっとも新しい形態のマニュアルで、今日では本の体裁よりも、ディ 
スクに書き込む形でューザーに提供される場合が多い。この最新形態のマニュアルは、古い夕 
イプのテクニカルライター、特にこの種のマニュアル作成に駆り出されたプログラマーや管理 
者にとっては、もっとも頭の痛い形式である。ところが面倒なことに、活字に対して拒否反応 
を示し、読むことによって何かを会得できる能力がほとんどないような読者（私は読者 X と呼 
ぶことにしている）が目立って増えているのである。 

「デモンストレーション」とは、その名の通り、実際にやって見せて理解させるものである。 
このデモンストレーションは、一般的に、システムを使って何をすべきかを承知しているュー 
ザーを対象としているため、ある業務の実行過程全体、あるいは作業内容全体が「トップダウ 
ン（総論から各論)」の形で説明されることとなる。反対にチュートリアルは、基本的な定義や 
コンセプトなどから説明を始めるという「ボトムアップ」の形態を取っている。 

籲リファレンスは経験者向け 

プログラマーの中には、「リファレンス」 を、誤って マニュアル そのものと同一視する者が 




役割：マニュアルは何をするか 
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図表〗. 5 くマニュアルの 4 つの役割> 

いるが、リファレンスとは、実例や情報を要約して提示するものであり、何を知りたいかが分 
かっている人にのみ有効なものである。経験を積み、高いレベルに達したオペレーターやユー 
ザーは、このリファレンスのほかに何も必要としないであろうが、初心者および高いレベルに 
到達していないユーザーやオペレーターは、リファレンスだけでは不充分である。 

_4つ目の役割：動機付け 

ユーザーの全体像の変化により、マニュアルには以上3つの機能のほかに、「動機付け」とい 
う4番目の機能を付け加える必要が出てきた。つまり、ユーザーがあえてやりたがらないことを、 
やるように仕向けるためのマニュアルの機能である。動機付けとは、要するに発想と手法の売 
込みである。すべてのマニュアルがこの動機付けを必要としているわけではないが、現状では 
動機付けがあまりにも欠如している。簡単にいえば、システム上の問題の中には、ユーザーが 
見すごしていることが原因というよりは、ユーザーの消極的対応を解消できないという点で、 
開発者側が責めを負うべきものが、数多く存在しているのである。「消極的」だったり、「欲張 
りすぎ」だったり、あるいは単に「怠慢」だったりすることが原因で、システムは多くの場合、 
われわれの考える本来の方法で使われてはいない。 

あたりまえのことであるが、ユーザーの動機付けを行なうには、ユーザー教育のためのマニュ 
アルとは種類の異なる書き方、つまり異なる形のユーザー •コント ロールを行なわなければな 
らない。これは、新米の事務員と経験豊かなインストーラーに対する教育が異なった方法で行 
なわれるのと同じくらい、自明なことである。 
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:マニュアルの成功と 
失敗を分けるもの 


2.1 マニュアルの最終目標：コントロール 
2.2 マニュアルを評価する4つの基準 
2.3 犯しやすい3つの誤り 
2.4 マニュアルの品質向上を妨げるもの 
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マニュアルを科学する 


2. 1マニュアルの最終目標：コントロール 


効果的なマニュアルを書こうとすると、次のようなパラドクスにぶつかる〇「こちらの意図を 
うまく伝えるためには、読者の主体性や理解力を尊重しなければならない。しかし、読者をか 
いかぶりすぎてはいけない。また、ほとんどの読者は、一方的な押しつけや命令には憤慨する 
のだが、押しつけや命令を必要とする読者は非常に多い」 0 ユーザー•マニュアルやオペレーショ 
ン • マニュアルを書く場合の最良の戦術とは、こうした一般的な読者のもつ弱点とうまく付き 
合うことであり、いいたいことの伝え方を自在に「コントロール」することである。 


•読者を情報処理のシステムとみなすべし 

マニュアルが、種々雑多な情報の寄集め以上の何ものでもないとしたら、マニュアルの有用 
性は初めから読者の理解力と懐の深さの問題ということになってしまう。反対に読者の能力と 
器量に合わせてマニュアルが作成されているならば、読者がマニュアルを誤って使用しないよ 
う、ある程度対処することができる。 

読者の能力と器量に合わせたマニュアル作りということを説明するのに、「コントロール」と 
いう言葉を使うと、そうとう非難を浴びそうである。人間をコントロールするということにな 
れば、深刻な倫理的問題を引き起こす。 

断わっておくが、私はマニュアルを書く際に、読者に何かを強要するような書き方をすべき 
だといっているのではない。また、たとえテキストや図表などの一部であっても読者の理解を 
強要できるなどとは考えていない。むしろ、効果的なマニュアルを書きたいと思っている人に 
は、読者というものを複雑な情報処理のシステムと見なして、そのシステムの引き起こすノイ 
ズやエラーの原因となるものをコントロールする術を学ぶべきであると提唱したい。 

人間の読解力や理解力については、未知の部分が多い。しかし、まったく分かっていないわ 
けではない。われわれは、読者を理解不全に陥らせたり、読者に間違いを犯させる原因につい 
て多くを知っているし、記憶力の効用についてもある程度分かっている。少なくともこれだけ 
はいえる。マニュアル作成者は、マニュアルの正しい使用を妨げる原因となり、特に読者の誤 
用を誘発すると思われるものを、マニュアルから排除しなければならないと。 

•マニュアルは読者をコントロールする 

要するに私は、マニュアルや他の情報製品は、コンピュータのプログラムがコンピュータに 
働きかけるのと同じように、読者に働きかけるということがいいたいのである。つまり、マニュ 
アルもプログラムも、その対象となるものをコントロールする。そして、設計不良のプロダラ 
ムが、システムの故障、中断、貴重な資源の無駄使いの原因となるように、マニュアルも設計 
をきちんとしないと、読者の理解不全、誤り、さらには作業の中断を引き起こしかねない。ま 
た、テスト段階のプログラムが、実行するたびにさまざまなバグを発生させるように、マニュ 
アルもテストを怠ると、読者がそれを手にするたびに誤りと矛盾をさらけ出してしまう。 

読者や ューザーをコン ト ロールす ることは、結局は読者や ューザー 自身の利益につながる。 
その狙いは、読者の意欲をそぐことも、作業能率を引き下げることもなく、読者の求めている 
ものを、もっとも効果的な筋道で読者自身が見出せるような仕組みにマニュアルを設計するこ 
とで' ある。 

(私はすべての文筆業務に ついてー ビジネス関係の文書作成の場合でもそのすべてに つい 
て一上述の考えを推奨するわけではない。文学というものは、読者の想像力、経験、知的能力 
に訴えかけることで成立している。卓越したエッセイを理解するには、精読と考察が多くの場 




要件：マニュアルの成功と失敗を分けるもの 
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合に必要となる0しかし、 内容を理解するために考察を必要とするようなマニュアルは、役に 
立たないのか'常である。） 


辞 書 

用語解説書 
目 録 

登録簿 


低 . コントロ 


操作手引書 
操作手順説明書 
企画書 
提案 書 


ルの度合い . 高 


図表 2.1 < マニュアル における ユーザー•コント ロー ルの度合い〉 


•コントロールの2つの極 

すべての出版物は、図表 2.1 の線上のどこかに必ず位置付けられる。もっともよくコントロー 
ルされた文書とは、読落とし、読飛ばし、拾読みがされることなく、最初から最後まで通して 
読まれるものである。このグループの中でよく知られているものには、システム導入計画書 
(installation plan ) 、システム組成手引書 (assembly instruction ) >初期トレーニング.プログ 
ラム （introductory training program ) 、提案書 ( proposal ) 、および仕様書などがある。この種 
のカテゴリーに含まれる文書は、ほぼ次の3つのタイプに分類できる。 

•段階発展型（次第に複雑な内容へと段階的に説明を積み重ねていくもの） 

• 連継手順型（つながりを持つ一連のステップや作業を提示するもの） 

• 論理展開型（主張を帰納的あるいは演繹的に展開するもの） 

この対極にあるのが、筋道立てて読まれることのない文書である。辞書、用語解説書、目録、 
登録簿というような、参照されるべき内容がアルファべット順や番号順に並べられたものがこ 
れである。もっとも、このようなコントロールの度合いが低い文書でも、読者をコントロール 
することには意味がある。巧みに設計されたリファレンスにおいては、読飛ばしや回り道をす 
ることもなく、“1回の検索”で必要な情報にたどりつくことができ、読者は迅速に目的の情報 
をそこから引き出すことができるからである。 
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マニュアルを科学する 


2.2 マニュアルを評価する4つの基準 


マニュアル 作成を、勘にたよるやり方から、文書作成工学に転換するための第ーステップは、 
どんな マニュアルが 望ましいかをテストする（あるいは マニュアルの 設計をテストする）ため 
の基準をはっきりと定義することである0たとえば、ある会社がその基準を受け入れることが 
できるなら、その会社は出版物の品質を評価するための指針あるいは尺度を、それらの基準に 
照らして独自に開発することも可能なはずである。出版物を評価する際にもっとも役に立つ基 
準を、 レベルの 低い方から高い方へ順に挙げると、「可用性」「適合性」「アクセス容易性」「可 
読性」ということになる。 


図表 2. 2は、品質保全工学の考え方を、ほんの少しマニュアルの草稿作成（あるいはヘルプ 
画面やチュートリアルの作成）に応用したものである。明らかにマニュアル作成には、品質評 
価に関して、少なくとも4つの基準がある。これは、段階を踏んで徐々にレベルが高くなってい 
くものであり、その段階は「可用性」（これがなくてはどうにもならない）から始まり、「可読 
性」（言葉として明快で理解しやすいこと）で終わる。 

•可用性（ユーザーが利用で吉ること） 

いまだに、ユーザー用文書を作成しようとしない開発者がいる。プログラマーだけで構成さ 
れている情報処理 ( DP ) 会社の場合は、たいていそうである。このような会社は、「ユーザーは 
何をするのか」「ユーザーは何を知っているのか」「ユーザーはどのように作業をするのか」と 
いった「ユーザー側の事情」にまったく無頓着である。したがってこのような会社は、ユーザー 
の事情に通じている人を雇い入れない限り、いつまでもマニュアル作成の重要性に気付かない 
ことになる。 

•適合性（ユーザーのニーズに合致していること） 

今日では、販売者および開発者の大半が、少なくとも何らかのマニュアルを作成している。 
しかし残念なことに、彼らはマニュアル作りに対し、百科事典でも編纂するようなやり方で臨 
む傾向にある。つまり、すべての情報を恐るべきボリュームの1冊にまとめようとし、ユーザー 
に自分で必要な情報を探させようとする。彼らがしなければならないのは、どのようなマニ 





基準 

必要作業 




可読性 

(スラスラと簡単に読めるか） 

専門家による編集 



アクセス容易性 
(構成が適切か） 

企画、設計 


適合性 

(ユーザーの業務と使用目的に合致してし\るか） 

分析 

可用性 



ユーザー事情 

(必要なとさに利用でぎるか） 

への精通 


図表 2.2 <マニュアルの品質基準とそのレベル〉 
















要件：マニュアルの成功と失敗を分けるもの 
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ュアルが必要とされるのかを「分析」する作業である。つまり、ある特定の読者の業務と使用 
目的にびったり合うマニュアル作りが必要なのである。特定の読者の ニーズに 合わせることが 
できなければ、“分かりやすく”作ったはずのマニュアルも、不適切で、使いにくく、信頼性に 
欠けるものになりかねない。 

•アクセス容易性（ユーザーが情報をアクセスしやすいこと） 

ユーザーのニーズに応えるものをちゃんと含んでいても、マニュアルの構成が使用に耐えな 
いほど入り組んでいる場合がある。このような場合読者は、ページを飛ばしたり（スキップ)、 
わき道にそれたり（ブランチ）、同じところを循環したり（ループ)、回り道（迂回）をしたり 
したあげく、結局わけが分からなくなってしまう。ソフトウェア • エンジニアリングの用語を 
借りれば、あまりに GOTO * の多いこのようなマニュアルは、信頼性に欠けるものである。この 
ようなマニュアルは、読み進む筋道が非常に入り組んでいるため、どんなに有能な読者でも、 
おそらくどこをどう読んだらいいのか分からなくなってしまうだろう。筋道を考えてマニュア 
ルを「設計」し、その設計をテストして、バグを取り除く作業を怠らない企業だけが、スムー 
ズに読むことのできる、 GOTO のないマニュアルを作成できるのである。正確で筋道の一貫し 
たマニュアルこそが、「業務別マニュアル」と呼ばれるのにふさわしい。これは、ユーザーの業 
務は何か、システムや製品をユーザーがどのように使用するか、ユーザーがどんな情報を必要 
としているかについて、開発者がきちんと分析しているマニュアルを指す。つまり、「業務別マ 
ニュアル」とは、ユーザーの求めるものだけが分かりやすい筋道で構成されているものである。 
•可読性（文章が読みやすいこと） 

マニュアルが正確で筋の通ったものでも、マニュアルの最終的な出来ばえは、その読みやす 
さにかかっている。つまり、マニュアルの対象読者が、いかに容易に、また正確にマニュアル 
を理解することができるかという問題である。情報処理 （ DP ) のかなり多くのプロが、いまだ 
に言葉と文体の問題を“飾り”程度に思っている。プロのライターやエディターによる簡単な 
チェックさえ受けていないマニュアルやインストラクシヨンが山ほどあるのは、そのためであ 
る。「専門的な編集作業」を経なければ、最高品質のマニュアルはあり得ない。 

したがって、ューザーが求める高品質のマニュアルは、「ユーザー側の事情への精通」、必要 
な情報の「分析」、「設計」と「テスト」、「プロの手による編集」によって初めて達成されるの 
である。もちろん、これらの作業がどの程度までやれるかは、個々の事情に制約される。しか 
し、各作業の最終期限を守りながら、利用できる機会をなるべく活かして各作業の内容を充実 
させるへ:きである。 


訳注* GOTO :プロダラミング言語の命令文の1つ。本書では、構造化プログラミングの手法を借りて、マニュ 
アル作成を構造化（モジュール化）した方法論が語られるが、 GOTO とは、モジュールの一連の正規 
の流れからいったん外に出て、まったく異種の処理を行なうため、他のモジュール「の方へ行く 」 （go 
to ) こと。 
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マニュアルを科学する 


2.3 犯しやすい3つの誤り 


4つの評価基準に照らして高品質といえるマニュアルを作るためには、まず正しい企画•設計 
がなされていなければならない。もしマニュアルがこの基準のどれかに照らしてみて、低い評 
価しか得られなかったら、「方針上の失敗」、「構造上の欠陥」、「表現上の失策」のうちのどれか 
に、その原因を見出すことができるはずである。 


マニュアルの欠陥の多くは、初稿が執筆される前のミスに起因する。しかし、この点はほと 
んど指摘されない。また、マニュアル作成におけるもっとも深刻な欠点は、 第一 稿が完璧に出 
来上がってしまった後では、ほとんど修正が不可能であるということだ。しかし、この点もほ 
とんど指摘されない。 

マニュアルの品質を損ねる誤りは、おおむね3っの段階で発生する。そして、編集の段階で修 
正できるのは、その中のわずか1つである。 

奉方針上の失敗 

まず最初の段階で犯される誤りは、「方針上の失敗」である。これは、プランニングと分析に 
おける失敗である。つまり、どんなマニュアルがいかなる読者に求められており、その読者は 
どんな作業に携わっているのかについて、正確な定義が行なわれていないために発生する失敗 
である。主な「方針上の失敗」は以下の通りである。 

• どんなマニュアルが必要とされているかについて、プランニングと分析を行なう必要性を 
見すごしている。 

• 製品やシステムには適合しているが、ユーザーの使用目的や作業内容を反映していない。 

• 1冊の汎用型マニュアルにしなければならないと考えてしまう。 

• マニュアルを対象読者のボキャブラリや読解力に合わせない。 

修構造上の欠陥 

「構造上の欠陥」とは、マニュアルの企画•設計とモデル構築における失敗である。つまり、 
マニュアルのアウトライン作成が充分に行なわれていない、アウトラインに対するチェックが 
あまい、細部の執筆を開始する前にマニュアル作成のプランに関してテストを行なっていない、 
などである。たとえ方針上の失敗がマニュアルに1っもなくとも、構造上の欠陥があればマニュ 
アルの「正確さ」は低下する。そして、さらに重要なことは、構造上の欠陥がマニュアルの筋 
道を混乱させ、極めて使いにくいマニュアルにしてしまうことである。もっとも一般的な構造 
上の欠陥は以下の通りである。 

•マニュアルのアウトライン作成もほとんど、あるいはまったく行なわず、その他のマニュ 
アル仕様書も作成しない。 

• レベルの低い見せかけのアウトライン作成手法にたよってしまう。 

•アウトラインと仕様書に対して厳しいチェックを行なわない。 

• 対象 ユーザーと 読者を設計の段階から排除してしまう。 

籲表現上の失策 

「表現上の失策」とは、編集と校正における失敗である。っまり、名称の不統一、文法上お 




要件：マニュアルの成功と失敗を分けるもの 
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よび表記（スペル）上のケアレスミス、ぎこちない未編集の文体、意味の曖昧な文章などであ 
る。表現上の誤りは、「初稿を編集するにあたり、どうすれば内容を明確に伝えられるか」につ 
いて充分心得ている人間が社内にいない場合、あるいはただ単に会社がエディターに作業に必 
要な時間を充分与えない場合に発生する。 

しかし、編集段階にはパラドクスがあることに注意して欲しい。まず、能力ある文章の専門 
家によってチヱックを受けずにマニュアルを印刷してしまうことは重大なミスである。また、 
書き方の悪いマニュアルが、エディターの技能によってよくなると信じるのはもっと危険であ 
る。 

したがって、マニュアルを使いやすくするには、以下の3つのテストを通さなければならない。 


どんな マニュアルに すべきかという方針はよいか、その マニュアルが 特定の ユーザー やそ 
の ニーズに 合致しているか、情報製品の セッ トまたは グループの中で その マニュアルが 過 
不足なく適切な役割を果たしているか、について検証する方針上のテスト。 

マニュアルの 構成要素が アクセス しやすく、信頼できる筋道の 中に 置かれて いるかについ 
て確認す る 構造上のテスト。 

文章や図表にケアレスミスやぎこちない感じがないか、加えて、どこにどう続くか分から 
ないような曖昧な文の流れで読者を悩ませていないか、について確認する表現上のテスト。 


図表 2.3 < 犯しやすい 3 つの誤り> 


誤り 

原因 

方針上の失敗 

(プランニング/分析の失敗） 

• 対象読者の明確化不足 

• ユーザーの作業内容の明確化不足 

• 全般的計画の欠如 

構造上の欠陥 

(設計とモデル構築の失敗） 

• 独立アウトラインの欠如 

•アウトラインに対するテスト不足 

• 検討作業からのユーザーの排除 

表現上の失策 

(編集と校正の失敗） 

• ケアレスミス 

• 文体のぎこちなさ 

• 未熟な編集 
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マニュアルを科学する 


2.4 マニュアルの品質向上を妨げるもの 


他に選ぶべき方法を示された後なお、なぜ多くの会社が、質の低い、欠陥だらけのマニユア 
ルを作り続けようとするのか。それは品質の向上に逆らって働く、組織的かつ心理的な強い力 
があるからである。すなわち「論争に対する恐れ」「近視眼的発想」「性急さ」「完全主義」の4 
つの障害である。 


多くの会社と多くのライターが、本書の示す方法に、心の底から賛同している。しかしそれ 
にもかかわらず、彼らはこの方法を現実に実行していない。彼らは、本書の問題設定と評価基 
準を支持している。また、本書がこれから述べる方法によって、問題が解決され、高い品質の 
マニュアルが作成できる、という点にも同意している。しかし、彼らはいつまでたっても、こ 
の方法を実行に移せないのである（ソフトウヱアの品質コンサルタントも、同じような問題を 
報告している）。この理由は何なのか。 

明らかにもっとも利益の上がることが、実行に移されないということは、この利益に対抗す 
る他の利益が存在しているからだとみてほぼ間違いない。マニュアル作成の場合、品質の高い 
マニュアルの作成を妨げ、同時に質の高いシステムの開発をもしりぞけてしまうこのような一 
連の「障害」は、人々を最善の方法から遠ざけ、より安易な方法である“早かろう悪かろう” 
式の方法を選ばせてしまう。これらの障害を図表 2. 4に掲げる。 


図表 2.4 くマニュアルの品質向上を妨げるもの〉 


障害 

傾向 

結果 

論争に対する恐れ 

意見対立と論争からの逃避 

テスト実施と問題解決の遅れ 

近視眼的発想 

短期コストに対する執着 

長期的利益の損失 

性急さ 

独善的な最終期限への固執 

製品/マニュアルの開発不全 

完全主義 

推測と予測に対する嫌悪 

優柔不断、無意味な遅れ 


籲「論争に対する恐れ j 

これは、方針や優先課題の決定に関するすべての対立を回避しようとすることである。特に、 
課や部の間における意見対立の回避などにみられる。これは、理解をなかなか示してくれない 
人、あまりにも多くの質問をする人、反対意見を提示する人などに対して、意思の疎通を図ろ 
うとしないことである。官民を問わず、大規模な官僚主義がはびこるところでは、論争の回避 
が重大な目標となり、利益や有用性や品質の追求といった事柄よりも優先されるのである。 
♦「近視眼的発想」 

これは、現時点において見通せる範囲内（進行中のプロジェクト）、または計算できる射程内 
(決算期）にあるもの以外に対しては、コストも成果もいっさい考えないことである。これは、 
将来に向けてのコストと利益を見積ろうとしないこと、すなわち短期的コストに重きを置き、 
長期的利益にまったく目を向けないことである。たいていの企業の出版部門は、この近視眼的 
な発想にとらわれており、その結果、出費を上回る利益が予想される事柄でも実行に移すこと 
ができずにいる。 
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•「性急さ J 

これは、たいていが（あるいはほとんどが）変更の可能な事柄を、あらかじめ決められた通 
り行なわなくては気がすまないことである。この症状は、近視眼的発想とも似ているが、特に 
急いで事を運ぶことを強調し、出来上がりの表面的な判断基準（ページ数、プログラムのステッ 
プ数など）を絶対化しようとする。事態を一層複雑にするのは、口では品質重視というが、実 
際には単に性急である多くの管理職の態度である。タイミングのよい“早かろう悪かろう型” 
の仕事をほめ、遅れた仕事は無条件に非難するのである。 

鲁「完全主義」 

これは、プランニングや価値判断に対して不平を述べることであり、はずれるかもしれない 
見通し、あるいは完了していない仕事や、やりかけの仕事についての討議をしぶることである。 
実務の中での完全主義は、優柔不断の姿勢とほとんど変わらない場合が多い。不充分なデータ 
にもとづく判断を避け、関わらないようにすることは、何の決断も行なわないのと同じである。 
しかも、追加情報を与えると、完全主義者は多くの場合、一層混乱してしまうのである。 

このような障害に進路をはばまれると、やる気のあるマニュアル作成者は、間違いなく欲求 
不満に陥る。このような作成者に投げかけられるのは次のような言葉である。“この問題は、後 
回しにしよう”（論争に対する恐れ）、“色刷りのコストが高すぎる”（近視眼的発想）、“とにか 
く金曜日までに終わらせてくれ”（性急さ）、“まず初稿を見た後で、どんな図表を使うべきかを 
決めよう”（完全主義)。 




. 





“有用性”:システムとしてのマニュアル 


3.1 “玄人向け”から“素人向け”へ 
3.2 マニュアルの第一原理 
3.3 マニュアルの有用性：その定義と評価 
3.4 よいマニュアルは並列型ではなく直列型 
3.5 激論！：有用性か経済性か 
3.6 最終テスト：信頼性と保守性 
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マニュアルを科学する 


3.1 “玄人向け”から“素人向け”へ 


技術者や発明家が、新しい製品や新しい技術の開発に真剣に取り組むときには、その製品が 
使いやすいかどうかには、ほとんどこだわらないのが普通である。しかしながら、1980年代に 
入ると、「有用性」が、コンピュータのソフトを企画する人間にとってもっとも重要な課題の1 
つになった。 


• システムの評価基準の推移 

今日のコンピュータ.システムの大部分は、1950年代のコンピュータが行なっていた作業と 
同じ作業を行なっている。異なる点は、スピードが速くなった、安くなった、人間の行なう手 
間が少なくなった、ということである。情報処理産業が登場して以来、コンピュータに対する 
評価基準は変わり、コンピュータにつぎ込まれる費用も、時を追うごとに急増してきている。 

図表 3.1 に見る通り、システムの品質に対する1950年代の一般的な基準は、「とにかくシステ 
ムが作動するかどうか」という点にあった。年月が経つにつれて、アナリストと エンジニアの 
関心は、「経済効率」へと向けられていった。つまり、スループット（一定時間あたりの仕事量）、 
サイクル•タイム（仕事あたりの所要時間）、資源（仕事に必要となる人材、機材、資材など） 
である。現在のものよりはるかに処理速度の遅い CPU (中央処理装置）のリース料のために、 

1秒あたり60ドル支払わなくてはならなかった時代においては、経済効率が重要だったのであ 
る。 

しかし、コンピュータとメモリーの価格が低下するにつれて、経済効率は、多くのところで 
あまり尊重されなくなった。現在では、マシンそのものの効率をアップするよりも、コンピュー 
夕をいかに効率よく使用するかを考える方が、個人にとっては安くつく場合が多い。今日にお 
いてもっとも重要で、よく話題に上がる実務的な基準は、「メンテナンスのしやすさ」である。 
つまり、システムの修正や調整や機能強化（バージョンアップ）などがいかにしやすいかとい 
うことである。 

1980年代に入ると、システムのテーマはいく分変わってきた。しかし情報処理 （ DP ) 会社や 
経営情報システム （ MIS ) 会社の多くは、依然として1970年代の レベルに さえ到達して いない。 





信頼性と有用性 
(中断がないこと） 

19日0年代 



メンテナンスと変更の容易さ 
(保守と機能強化が簡単であること） 

197□年代 


効率のよさ 

(コンピュータの性能を充分引き出せること） 

1960年代 

何らかの成果が得られること 
(とにかくシステムが作動すること） 

195□年代 


図表 3.1 < システムに対する品質評価基準の推移〉 
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というのは、彼らは新しい開発手法のメリットを活用せずに、メンテナンスのしにくいシステ 
ムを組み上げ続けているからである。ところが、最近のテーマは“ユーザーにとってのなじみ 
やすさ”、つまりシステムをいかに使いやすくするか、ということである。 

コンピュータ•テクノロジーは、1つの開発サイクル全体を完結させた感がある。ほとんどの 
部分において、やっている内容は初期のころと変わりはない。变わったのは、ユーザーに対す 
る姿勢が親切になったという点である。今日のオペレーターは、数学者やプログラマーではな 
く、事務員やビジネスマンが主流であり、10歳の子供さえいる。エンジニアは、今日の新しい 
システムを“専門家向け”と考えてはならない。そうしたいのなら、ユーザーが専門家によっ 
て占められていたコンピュータの草創期にまで、さかのぼらなくてはならないだろう。 
•システムの有用性とは何か 

“ユーザーにとってのなじみやすさ”というよりも「有用性（使いやすさ）」といった方が分 
かりやすいだろう。この有用性とは、使いにくさを「巧みな設計によって解消すること」であ 
る。つまり、デバイス、システム、プログラムなどが持つ表面には現われない部分の操作性に 
よって、それら自身が可能な限り使いやすい状態になる、ということである。どのようにマニュ 
アルが書かれるにせよ、20回キーを押さなければならない作業よりは、2回の方が楽である。ま 
た、“画面クリア”のボタンが“文字挿入”のボタンのすぐ横に置かれていたら、マニュアルで 
いくら注意を与えておいても、うっかりして画面を消去してしまう場合が出てくる。しかし、 
ボタンの位置をほんの少し移動させれば、この誤操作の頻度は低下するのである。 

もちろん、有用性と対立するさまざまな概念がある。たとえば、初心者が操作を覚えやすい 
ようにシステムを設計したとしても、長期的に見て、その設計が日々の操作を簡便にするとは 
限らない。有用性とは、システムが充分に企画•設計、テストされていなければ得られない結 
果である。有用性は、充分な分析と企画•設計によって、初めて生まれるものであって、いく 
ら立派なマニュアルを書いてもシステムが使いやすくなるわけではない。 

特にマニュアル作成者にとって、「有用性」という言葉は、2つの重要な意味を持つ。第一は、 
システムが操作される上での使いやすさであり、第二は、マニュアルが使用される上での使い 
やすさである。言い換えるならば、本書を通じて私が主張しているように、マニュアルを1つの 
システムと考えると、コンピュータ•システムの有用性が充分発揮されるか否かは、マニュア 
ルの有用性のレベルによつて決まることになる。マニュアルが使いやすければ、 コンピュータ* 
システムが、その本来の使いにくさよりも、使いにくくなることはない。マニュアルと他の情 
報製品が、ともに最高の有用性を持っているならば、これらで説明されたシステムは、意図さ 
れた通りに使いやすいものとなるだろう。しかし、マニュアルに誤りや欠陥があればあるほど、 
システムはその有用性を低下させていく。 
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マニュアルを科学する 


3.2 マニュアルの第一原理 


システムやソフトがそれぞれ固有の有用性を持っているように、システムに添付されたマ 
ニュ アルにも、それ自体の有用性がある。しかし、どんなに出来のいい マニュアル でも、シス 
テム自体の持つ欠点を充分に補うことはできない 0 そこで第一原理はこうである： 

完全無欠のマニュアルが、出来の悪いシステムを改善することはあり得ない。 


•システムの不備はマニュアルでカバーで$ない 

ひとたびシステムが動き始めると、もはやその操作性を根本的に変えることは、ほとんど不 
可能になる。仮に改善されたとしても、ほとんどの場合それは表面的なものにすぎない。シス 
テムの不備を“とびきり出来のいい”マニュアルでカバーしようとするような方法で、既存の 
システムの有用性を高めようとしても、まったく効果は期待できない。（要するに、道にあいて 
いる穴をそのままにしておいても、警告さえすれば危険ではない、とたかをくくるようなもの 
だ。) 

地図を描いたからといって、ジャングルを緑園に変えることは不可能だ。同様に、面倒でや 
やこしい処理手順は、出来のよいオペレーション•ガイドを作っても、ューザーにとって親し 
みやすくはならない。事後にマニュアルが作成される場合（最初にシステムを開発して、その 
後にマニュアルを作成する場合）、そのマニュアルでシステムの分析、企画、プログラミングな 
どの欠陥を補うのは、絶対に無理である。 

本書は、マニュアルに関するものであるはずなのに、このように書くのは蛇足だと思われる 
であろう。しかし、マニュアルに過度な期待を寄せるのは間違っている。マニュアルで設計ミ 
スやプログラムのミスを正そうとしてはならないのだ。 

処理手順の簡単なシステムは、きちんと説明されれば、とても分かりやすいものである。逆 
に難解な処理手順のものや、あぶなっかしくてトラブルを起こしやすいものは、いくら説明が 
よくても、依然としてそのような欠点が改善されるわけではない。 出来の悪いマニュアルが操 
作手順を分かりにく くすることはあるとしても、優れたマニュアルが手順を簡単にすることは 

あり「得ない」。 

•マニュアルはシステムが完成する前に書け 

マニュアルがシステムを改善する方法はただ1つ、システムが出来上がる前に、マニュアルを 
作成することだ。マニュアルのライターは、システムの“最初のューザー”となるわけだから、 
システム開発者が見落としがちな改善の方法を見つけることができる。そして、システムがディ 
スクに組み込まれる前に、マニュアルをきちんと書くことができれば、システムを設計し直す 
時間もできるのではないか。 

図表 3.2 で分かるように、マニュアルがシステムの機能仕様書作成の段階で書かれる（少なく 
とも設計される）ならば、そのマニュアルは、システム設計のモデルとして使用できる。開発 
者はシステムが人間と直接関わる部分一いわゆる“ューザー•インターフェイス”一のエラーや 
曖昧な部分を見つけ出し、訂正することができる。システム設計の段階に入ってからでも、説 
明しにくい操作手順が見つかれば、文書化を進めているシステムの各モジュールを手直しする 
チャンスは残っている。この種の手直しは、この段階ならまだ' 6 T 能である。しかし開発の最終 
段階になると、マニュアル作成者は多かれ少なかれ、システムの仕様に制約されてしまうもの 
である。 

要するに、有能なライターによる分かりやすい解説をはねつけるような操作手順は、たいて 
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図表 3.2 くマニュアルの第一原理> 


マニュアルの開発時期 

マニュアルの働き 

製品/システムの機能仕様定義時 

• 製品の操作手順と開発方針が明確化できる 
• ューザーに不親切な要素が識別できる 

-ューザーの目標達成率を高められる 

製品の設計/プログラミング時 

• バグやエラーをつきとめられる 

• 製品不信の原因を明らかにできる 

• 設計者の迅速な決定を促すことができる 

製品の引渡しおよび使用時 

• 製品にューザーが適応できるようにすることができる 
• システム内のバグに対して警告を発することができる 
• 製品に対するマニュアルの責任は回避される 

い理解しにくい。電車の時刻表ほどもあるような例外集と注意書きがなければ説明できないよ 
うな業務は、おそらく能率よく行なわれることはないだろう。適切な環境があれば、システム 
あるいは操作手順が確定する前、すなわちシステム変更に費用がかかり、しかも面倒になる前 
に、これらの問題点がはっきりするはずだ。マニュアル作成者が、操作手順の変更を促すこと 
によって、回りくどい説明を要したページが、数ページまるごと削除できることもある。雑然 
として曖昧な操作手順ほど、マニュアル作成をやっかいにするものはない。逆に、マニュアル 

の記述が雑然として曖昧であれば、 

使いやすいシステムも使いにく くなってしまう。 

皮肉なことだが、次のことがいえる。システムの設計がよければよいほど、マニュアルの必 


要性は低くなる。システムの不備を早い時期に見つければ見つけるほど、書くべき量を減らす 
ことができる。 
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マニュアルを科学する 


3.3 マニュアルの有用性：その定義と評価 


マニュアル 作成の課題が有用性を考慮していかに企画 • 設計するかということであるなら、 
そしてその作成過程が“芸術’’とは無関係のものであるなら、そこには何かしら一定の評価基 
準が必要である。有用性のための指標としては、まず次のことを考えるべきである。対象とな 
る読者が部分的に読み飛ばしたり、読み返さなければならないような事態が増えれば増えるほ 
ど、その マニュアルは 使いにく くなる。 


•スキップ（読飛ばし）や後戻りはマニュアルをダメにする 

マニュアルの 出来がよいからといって、必ずしもシステムが優れているとはいえない。しか 
し、システムを成功させるためには、出来のよい マニュアルが 不可欠な要件となる。 

評価の基準 一 有用性を高めるための指標一はいろいろ考えられるが、 マニュアルを 書く前、 
すなわち予想される不備や誤りが全部手直しできる時点で使えるような評価基準を設定するこ 
とができるはずである。「製品は開発期間の後になればなるほど変更に費用がかかり、したがっ 
て、実質的に変更不可能になっていくものである」。この基本を忘れてはならない。 

経験に照らし合わせて、私は次のように結論付ける。対象となる読者がマニュアルを使う際、 
何度スキップしたか、何度後戻りしたか、その回数がもっとも適切な有用性の指標となる（も 
ちろんこれは「逆説的な」言い方である）。 

だからといって、何もす ベての マニュアルについて、あらゆる読者が最初の一語から最後の 
一語まで、順番に読めるように作成すべきだというのではない。実際、そのようなマニュアル 
は皆無といってよい。それでもスキップや後戻りは、わざとにせよ、そうでないにせよ、マニュ 
アルを使いにく くするといいたい。 

指標の定義の中で“対象となる読者”という言葉を使ったことに注意していただきたい。読 
み手の目的や状況が異なれば、当然、同じマニュアルでも使い方は違ってくる。 すべての 文章 
を順番に読む人もいるだろうし、飛ばしながら拾い読みをする人もいるだろう。また同じ読者 
でも、1度か2度通して読んだ後、飛ばしながら拾い読みをすることもある。当然、マニュアル 
の読者層が多様になればなるほど、あらゆる読者に使いやすいようにするのは困難になるもの 
だ。 

籲3つの誤りに照らしてみると 

おもしろいことに、スキップ（読飛ばし）やループ（循環）（分岐、迂回、 GOTO ) は、マニュ 
アルの3種類の主な誤りに対応させることによって、3つのグループに分類できる。 

•「方針上の失敗」は、もっとも大きいスパンのスキップや方向転換の原因となる。 

本が読者の目的に合っていなければ、読者は必要なものが見つかるかそれを諦めるま 
で、 本から本へ飛び移ることになる。1つの仕事に2冊の本が必要になるということは、 
ューザーのニーズや利益が、本の内容選択や分割の仕方に反映されていないというこ 
とになる。また、ューザーがある マニュアルの 98%を無視しなければならないとした 
ら、その マニュアルは 別のューザー向きに設計されたもの、ということになる。 

•「構造上の欠陥」は、中間的なスパンのループ（循環）やスキップ（読飛ばし）の原因 
となる。この種の マニュアルには、 前から後ろへ飛ばさなくてはならないことがたび 
たびあるが、他のページにある図や表、一覧などを参照するよう指示してある場合は、 
特にその回数が多くなる。（注：マニュアルの有用性を妨げる 一番 大きな原因は、本文 
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図表 3.3 <マニュアルの有用性を評価する> 


基準 誤り 結果 


可 用 性 


適 合 性 


アクセス容易性 


可 読 性 


方針上の失敗 


構造上の欠陥 


f -本から本へ飛び移る 
-1つの作業に2冊の本を必要とする 
[ -大半のページを無視しなければならない 

f -本の最初から最後に飛ぶ 
| -ページ通りに読まない 
[ -図や表を探し回る 


(.ケアレスミスが気になって集中できない 
表現上の失策 •不統一な用語に当惑する 

[ -難しい部分を読み返す 


と参照すべき図表が離れているということである。） 

•「表現上の失策」による GOTO は、一番小さいスパンのものである。普通は1段落か1 
ページですむ。編集がまずいために、読者は意味が不明瞭な文や、専門用語の不統一 
性や、文法上の誤りなどにとまどってしまうに違いない。有用性を損なう原因として 
は最も小さいものだが、このようなミスがあると、構成のしっかりした優れた本でも、 
評価は低くなる。 

以上のように定義しておけば、有用性を企画 • 設計の初期の段階で評価することができる。 
方針上の失敗はープランをテストする場合に—マニュアルのブランの中にループ（循環）を発 
生させる原因となる。構造上の欠陥はーアウトラインを正確に組み立て、テストする場合に一 
そのマニュアルのアウトラインの中にループや GOTO を生じさせる。表現上の失策だけは、マ 
ニュアルの草稿が完成してから現われる。 
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マニュアルを科学する 


3.4 よし、マニュアルは並列型ではなく直列型 


並列型の マニュアルとは、ソフト やシステムの操作に関するあらゆることを、説明の対象と 
なるものの性質ごとに構成したものである。直列型の マニュアルとは、 ある一定の事柄を、読 
み手が実際に操作する手順や業務内容に沿って構成したものである。並列型の マニュアルは、 
「リファレンス •ブック（参照 書)」 である0したがって、たいていの場合、 ユーザー 教育用、 
あるいはデ モンストレーシヨン 用としては使いづらい。 


•どんなに多機能でも目的は1つ 

コンピュータの出初めのころは、プログラムの機能は1つか2つしかなかった。選択肢、ある 
いは“ユーザー定義 オプション” は、ほとんどなかった。したがって、 Run - Book (実行指示書）* 
は単純で、すっきりしていて、読みやすく、作業本位にできていた。 

しかし、今日のシステムの傾向は、できるだけ多くの適応業務を遂行する方向に向かってい 
る。そして高級言語、データベース管理システム、あらゆる統計分析やグラフィック表示を行 
なうパッケージなどがそのために作られている。 

このような多目的 システムの ユーザー. マニュアル や オペレーション.マニュアルを 作成す 
る場合、重大な方針上の問題が生じる可能性がある。マニュアル作成者は、このことをよく分 
かっていなくてはならない。多くのューザーは、包括的な機能や特徴が何十個あっても、その 
ようなことには無関心である。たとえば、開発者にとっては、もっとも大切な研究課題の1つに 
“パラメータ（媒介蛮数）をどのように定義付けるか”ということがあるが、医者や倉庫管理者 
は、そのようなことには興味を示さないだろう。 

ここにパラドクスが生じる。多機能ソフトには、たとえば大型汎用コンピュータで動くデー 
タベース管理ソフトや、一般的なパソコン用に設計された競合する各種“スプレッドシート” 
ソフトなどがある。しかしこのような多機能ソフトの大半が使用されるのは、適応実務におい 
てである。ソフトを開発した個人あるいは企業は、その多機能性を手放しで誇りに思っている 
し、コンピュータに熟達している洗練されたユーザーは、ソフトの利用法をいくらでも考え出 
すことができるだろう。ところが、大部分のユーザーは、「自分たち」のプロジェクトの進め方、 
「自分たち」の問題の解決方法、「自分たち」の業務の改善策を知りたいと思っているのである。 
•ユーザーには固有の利益がある 

マニュアルに 盛り込まなくてはならないのは、次の3種類の情報である。 

• 「ユーザー」の職場にシステムを導入する際に必要となる情報。 

• 「ユーザーが自分で」アプリケーション•プログラムを作成するためにシステムをどのよう 
に利用したらよいかを、「ユーザーの実際のニーズ」や利益をもとにした例を用いて指 
導した情報。 

•または、「特定のユーザー」の問題解決のためにあらかじめ作られた「アプリケーション* 
プログラム」。 

この3種類の情報のうち、今日の開発者にとって、最初の2つは3番目に比べてはるかに有用で 
あり、3番目には何ら発展性がないように感じられるかもしれない。驚くべき多機能性を誇るソ 
フトを、まるで1つの機能しか果たさないアプリケーションのように扱ったマニュアルを書きた 
がる理由がどこにあろうか。そんなマニュアルは、ソフトの価値を下げはしないだろうか。 

否、まったく逆である。ユーザーにソフトの使い道をよりはっきりと示すことになり、した 
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がって マニュアルは、 より使いやすくなるのだ。 読者には、独自の使用目的や利益を持つ権利 
が与えられるべきである。 多機能のソフトや ハー ドを、 スピーカー や テレビゲームと 同じよう 
に、1つの機能を果たす道具にすぎないものとして扱っても構わないはずである。 

秦並列型と直列型 

図表 3.4 のアウトラインの比較を見て欲しい。2つのタイプの間には、共通の項目がたくさん 
あることにお気付きだろうか。双方のスタイルにはいくつか興味深い違いがある（このことは 
後で述べる）が、主な違いは、 A は並列型であり、 B は直列型であるということだ。 A を用い 
るユーザーは、ひっきりなしにスキップ（読飛ばし）やループ（循環）をしなくてはならず、 
このようにマニュアルが使いにくくなれば、ソフトの有用性も引き下げられることになる 。 BO 
方は、実務に即して構成されている。使ってみると、 B の方がずっと信頼できるはずである。 

図表 3.4 <並列型マニュアルと直列型マニュアルの対比〉 


A タイプ(並列型） B タイプ(直列型) 


1. システム管理 

1.1 機密保護機能の省略時解釈 
1.2 装置構成の定義 
1.3 ファイルの 初期設定 

2. ファイル管理 

2.1 ファイルの定義 
2.2 ファイルの読込み 
2.3 ファイルのリンク 
2.4 ファイルの 更新/保守 

3. 人力準備 

3.1 ワークシート 
3.2 データ入力 
3.3 データ編集 

4. 出力 
4.1 印刷 

4.2 図表の印刷/点描 
4.3 保存 

付録 I 代替システム構成 

付録 II 出カサンプル 

付録 III エラーメッセージー覧 


1. システムを導入する 

1.1 添付ディスクのパ'ックアップを取る 
1.2 会社の機密保護に関する規則を定義する 

2. ファイルを作成する 

2.1 システムに科目体系を登録する 
2.2 仕訳伝票を入力する 

2.3 一連の“ファクター‘プランニング”プログラムを書く 

3. 適応業務 

3.1 損益分岐点により損益を分析する方法 
3.2 年度別原価差益を比較する方法 
3.3 収支を予測する方法 
3.4 予算案をシミュレートする方法 
3.5 収益実績をシミュレートする方法 

4. 報告書作成 

4.1 傾向チャートを作成するぢ法 
4.2 分担チャートを作成する方法 
4.3 比較チャートを作成する方法 
4.4 各種の表を作成する方法 


訳注* Run-Book :特に事務計算などでは、使用するデータ、入出力装置、ブログラムなどが、処理によってす 
ベて異なる場合がある。こうした計算処理を，いつでも誰でも正しく行えるよう、その手順や扱い方 
が書かれた指示書。 
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マニュアルを科学する 


3.5 激論！：有用性か経済性か 


マニュアルを 使いやすくしようとすると、繰返しや重複、浪費（出版部門の責任者はそう呼 
ぶだろう）につながる数多くのことをあえて行なわなければならないことが分かってくる。有 
用性と経済性の目指すものはしばしば対立する〇その対立は基本方針の設定と充分な話し合い 
を経て、解消されるべきである。 


•スペースを節約するな 

会社でマニュアル作成を指揮するのは、出版部門の管理職が多い。皮肉なことに、管理職が 
まず優先するのは、たいてい「生産の経済効率」であり、マニュアルなどにかける費用は、ぎ 
りぎりに抑えなくてはならないものである。 

しかし、その結果マニュアルの出来があまりよくなかったために大きな無駄が生じて、一時 
的に節約したコストなど問題にならなくしてしまう場合もある。また、マニュアルの作成や発 
行や保管にかかる費用を削減すると、マニュアルの読みやすさまで削減されてしまう。たとえ 
ば、マイクロ フィ ルムや細かい印刷文字を喜んで読む ユーザーが いるだろうか。「出版社は、同 
じことを二度印刷せずにすんでさぞかしよかったろう」といいながら、本の2つの章を喜んで 
行ったり来たりする読者などいるだろうか。 

情報の入る「スペース」（本の場合はページ数）を減らすのによく用いられる方法を考えてみ 
よう。小さい文字で印刷したり、上下左右の余白をなるべく狭くすることは、ページ数を減ら 
す一番簡単な方法であり、印刷、発送、保管にかかるコストも削減されるだろう。たとえば、 
ある米国大手の技術情報サービス*は、シングル （1 文字分の）スペースと、3/4インチのマー 
ジンを力説している。結果は、ぎっしり詰まったほとんど読めない報告書となる。 

同様に編集者や発行者の多くは、余白部分や半分空白のページを嫌う。しかし、本書では、 
各セクションの冒頭を必ず新しいページに持ってくる、というやり方を提唱している（またそ 
れを実践している）。結果は、ゆったりした読みやすい文書となる。 

籲 redundancy は f 言頼性を意味する 

もっとも論議の的になるのは 「 redundancy 」 である。これは学生時代に書いたレポートや論 
文に対する批判としていわれた覚えがあるだろう。しかし、この redundancy は、必ずしも批判 
のためだけの用語ではない。エンジニアリングにおける redundancy は、慎重を期すための 
“バックアップ”手順や手段のことを指すのであり、基本のデバイスが壊れたり、うまく機能し 
ない場合でも、システムを動かしておけるようにする技術である。 スーツに 縫い込まれた替え 
ボタンから、原子力発電所の冷却ポンプを作動させるのに使われる3機ないし4機の予備電源に 
至るまで、発想は同じである。 redundancy は信頼性を意味する。 

通信工学では、 redundancy とは、通信チャンネルにおけるノイズやエントロピー*を補正す 
るものである。雑音の多いチャンネルから正確な信号をキャッチする一番間違いのない方法は、 
何度も発信することである。パイロットが管制塔と話すときに「はい了解」と繰り返すのも、 
電信による資金為替が最低2回に渡って送信され、パリティ•チヱック（奇偶検査）*が行なわれ 
るのもこのためである。 

場合によっては、文字が大きく、上下左右の余白が広く、章の終わりに空白が取ってあるこ 
とさえ、情報が雑然として筋道が分かりにく くなることが回避できるという意味で、印刷技術 
から見た redundancy の発現形態であるといえる〇 redundancy がもっと明確な形で現われるの 
は、実際に「繰り返される」（同じ文や図表が明らかに2ヶ所以上で用いられる）場合である。 
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しかし、出版部門の管理職にとっては、こんなことは考慮の対象外のことだろう。さらに興味 
深いのは、技術雑誌の編集者のほとんどすべてが、すでに本文で述べたことを絵や図に描き換 
えるというやり方をいやがるということである。文章でうまく表現できたことを繰り返し図に 
表わす必要があるのか、と彼らはいうだろう。 

•読者によって書き分ける 

マニュアルの短期的なコストが気になって仕方のない人々は、図表やイラストは、必要でな 
い限り、つまり文章だけでは表現できないものを示すとき以外は用いるべきではない、と本気 
で信じているようだ。しかしながら、よく出来たマニュアルでは、絵や図で文が“バックアッ 
プ”されるのだといいたい（その逆もいえる）。というのは、言葉を得意とする読み手と図表を 
得意とする読み手がいるため、もし読者のニーズに応えて、マニュアルが正しく読まれるよう 
にしたいのなら、双方の読み手のために書くべきだからである。 

故意の繰返しや redundancy がすべて望ましく効果的である、というのではない 0 それがあま 
り適切でない場合もある。くどすぎることもあるし、使いやすさという基準に合わなくなるこ 
とさえある。また、 redundancy の度合いと形式は、マニュアルとユーザーの関わり方にもよる。 
大学院の学生向けのテキストに比べると、オペレーション•ガイドは、より多くの redundancy 
が必要だ。そして、経験のない事務員や作業員向けのオペレーション•ガイドには、経験者向 
けよりも多くの redundancy が必要である 0 
•目先の節約にとらわれるな 

まれに、運よく経済性と有用性を兼ね備えている場合がある。しかし、マニュアルを使いや 
すくするという条件のほとんど（たとえば、丈夫で厚い紙、カラー印刷など）は、とりあえず 
高くついて無駄のように思われる。しかし、それは目先だけのコストを見た場合である。長い 
目で見ると、効率性や生産性が高まって、何倍ものコストが節約できる。大局的な見方をすれ 
ば、マニュアルを読みやすくするための出費は、フィールド.サービス、ホットライン、ユー 
ザー•トレーニング、トラブル対策など、さまざまなユーザー•サービスにかかるコストを省 
く、すなわちすでにそれらを含んでいるといえる。 

優れたマニュアルは何倍も元が取れるはずだ。マニュアルの質を高める功労者は、四半期の 
予算にではなく、「総体的」なコストに気を配る人であり、結局そのような人を抱えているとこ 
ろが、最良のマニュアルを作る会社なのである。 


原注* *技術情報サービス：米国には、新しい記事や技術報告書などに関する目録、要約、抜粋などを提供する 
組織が数多くある。利用者の会費によって運営される民間企業の場合もあり、安い費用で誰でも利用 
できる公共機関の場合もある。 

訳注*エントロピー：その通信チャンネルで送ることのできる情報量の尺度の1つ。 redundancy 、 ノイズ、エ 
ントロピーの3つの尺度で、その通信路の情報量を測ることができる。 

*パリティ•チヱック：データの信頼度を上げるために余分な情報を付力卩する方法。 
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マニュアルを科学する 


3.6 最終テスト：信頼性と保守性 


有用性のチェック項目 （マニュアルが スキップ、ブランチ、ループ、回り道などをどの程度 
克服しているか）は、恣意的なものでも感覚的なものでもない。それは、システムを作動させ 
たり、サボートする場合の費用に直接関わるものである。使いやすい マニュアルとは 、「信頼性」 

と「保守性（メンテナンスのしやすさ）」に優れたものでなければならない。つまりうまく使え 
ないことがなるべく少なくなるように書かれたものであり、また、問題がある場合の修正や調 
整が簡単にできるものでなければならない。 


•マニュアルの信頼性とは何か 

文書作成を1つのシステムと考え、各マニュアルがシステムの構成要素、あるいはデバイス（装 
置）であるとするならば、各マニュアルはできるだけ信頼性の高い、メンテナンスのしやすい 
形で作成すべきであろう。 

ところで“マニュアルの信頼性”とは何であろうか。マニュアルが“失敗”するとは、どう 
いうことなのだろうか。平均故障発生間隔 （MTBF :工学におけるもっとも一般的な信頼性測 
定法）*によって、マニュアルが評価できるのだろうか。マニュアルが“故障”することが本当 
にあるのだろうか。 

マニュアルが原因で ューザーやオペレーターの 仕事ができな く なった、 つま り誤操作、故障、 
中断などの直接的な原因がマニュアルにある場合は、マニュアルの失敗といえる。したがって、 
マニュアルの失敗は、書かれなかった情報、間違った情報、曖昧なあるいは矛盾した情報によっ 
て引.き起こされる。また、必要な情報を探すのにかなりの努力が必要になるような形で内容の 
配列がなされている場合も、スタート地点を間違えたり、無駄な努力を払ったり、そのマニ ュ 
アルでは処理できない問題を“その場しのぎ”の方法で解決しようとしたりするという障害が 
引き起こされる。 

誤操作と作業中断という2つの失敗のうち、どちらの方が高くつくのかを判断するのは難し 
い。作業中断の方が一般的ではある。なぜなら職場では“作業中断時はコーヒータイム”とな っ 
てしまうため、金を支払って従業員を休ませることになってしまう。しかし、おそらくもっと 
も高くつく失敗は“読者に誤解されても仕方のない”ような マニュアルの 記述によって、 ファ 
イルの破損やその他の深刻な破壊が発生することである。 

癱有用性と信頼性の関係 

有用性を測る指標が正当なものであるということは、次のようなことからもよく分かる。1冊 
のマニュアルの中では、スキップ（読飛ばし）やループ（循環）による複雑さと、エラーや故 
障の起こりやすさとの間には、はっきりした因果関係がある。マニュアルに筋道が多ければ多 
いほど、間違った道を通る可能性も高い。また、マニュアルを読む際に不連続の動きや選択肢 
が多ければ多いほど、間違った動きや選択をする可能性が高い。 

この考え方は、あまり経験のない読者、特にマニュアルを読む能力があまりない読者には、 
間違いなくあてはまる。しかしこの原則が、難しいマニュアルをうまく読めない読者にだけあ 
てはまると勘違いしてはならない。入り組んでいて、信頼性に欠けるマニュアルを読み慣れて 
いる読者もいるが、決して好きで読んでいるわけではない。 

出来の悪い雑然としたマニュアルが、筋道の一貫した GOTO のないマニュアルと同じように 
安心して読めないことは明らかである。 

信頼性は1つの目標とみなし得る。読者 X (マニュアルの内容を読み取るのに苦労している） 
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信頼性、保守性が低い 
(失敗が多く、回復が遅い) 


生産的な使用の度合い 



時間 


信頼性、保守性が高い 
(失敗が少なく、回復も早い) 


生産的な使用の度合い 



図表 3.6 <信頼性と保守性の向上> 

を扱おうとしているマニュアル作成者は、目標を高く置いた方がよい。読者 Y (複雑なマニュ 
アルに慣れていて怖がらない）を対象とするライターは、目標を比較的低く置いてもよいだろ 
1 〇 

參信頼性の高いマニュアルはメンテナンスもしやすい 

信頼性は、その目標をどの レベルに 置こうと、マニュアルが“失敗”する頻度をもっともよ 
く示すものだ。この考え方は、「メンテナンスのしやすさ」につながる。つまり、ューザーが ミ 
スを修正して、再び作業にとりかかれるまでに、どのくらいの時間を要するか、ということで 
ある。錯綜やループ（循環）はューザーの仕事を複雑にするが、同様にマニュアルの不備な点 
を見っけたり、変更したりする作業をも複雑にする。 

マニュアルが入り組んでいて使いにくいと、潜在的で解決が困難な問題が起こる。たとえば、 
あるページで1ヶ所変更すると、別の所で信じられないような、まったく予期できないエラーが 
発生することがある。マニュアルからある図表を削除した場合に、その図表に関するあらゆる 
コメントを間違いなく削除できるだろうか。ある報告書の名前を変更した場合に、それが現わ 
れる個所をすべて間違いなく変更できるだろうか。制限事項を緩和した場合に、その制限に関 
わる操作すべてに、間違いなく言及できるものだろうか。 

マニュアル 自体を変更することも、やはり混乱を引き起こす原因となり得る。 マニュアルの 
中には、すんなりと補足や修正を受け入れるもの（メンテナンスしやすいもの）もあるが、そ 
れを 拒むものもある。標準 マニュアルを たびたび改訂している DP センターの中には、どの マ 
ニュアルを 取っても、同 じバージヨンの ものは2つと見あたらな いという ところもある。 


訳注*平均故障発生間隔 ： Mean Time Between Failure 。 故障が発生してから、次の故障が起きるまでの時 
間の平均。 
































マニユア/レへの構造的アプロ 
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“土壌”:マ ニ ュアルはいかに書かれるか 


4.1 マニュアルを“書く” 2つの方法 

4.2 プログラミングの歴史から学ぶもの 

4.3 マニュアル作成を効果的に進める5つのプロセス 
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マニュアルへの 構造的 アプローチ 


4.1 マニュアルを“書ぐ’2つの方法 


マニュアルを 書くには、大きく分けて2つの方法がある01つは、「執筆•構成する」という方 
法（“作家”が原稿に向かってそうするように、文章や段落をいろいろ工夫してみるやり方）で 
ある。もう1つは、「企画•設計する」という方法（段階を踏んで徐々に詳しくなっていき、つ 
いには マニュアルが“ 必要でなくなってしまう”ような一連の仕様書を作成するやり方）であ 
る。 


•プロはプランニングを行なわない7 

“ライター”という言葉から人々が思い描〈イメージは、原稿用紙の上の1行1行の文章に対 
して一所懸命取り組んでいる人ということだろう。そこには、ひらめいてなぐり書きする、そ 
して猛烈に推敲し、手直しする、また手が止まって次のひらめきをじっと待つ、といった一連 
の作業がある。 

コンピュータのプログラマー にも、同じような一般的イメージがある。つまり、試行錯誤、 
着想からの推論、天才的なひらめきなどを通してキーボードをたたきながら考える人、といっ 
たイメー ジである。 

このような紋切型のイメージのプログラマーやライターは、実際に存在している。彼らにとっ 
てのプログラミングおよびマニュアル作成とは、ルーズで、非計画的で、“芸術的な”やり方で 
片付けられるような、かなり単純なプロジェクトである。実際、プログラマーやテクニカルラ 
イターは、何のためらいもなく、ほとんど明確化されていないプロジェクトに、のべ3、4ヶ月 
も費やして、よい結果が出ることを期待するという意味では極めて特異な存在である。 

もちろん、どの分野においても、まったくプランニングを行なわずに仕事をするプロが、ご 
くわずかだが存在する。このようなプロは、上述のプログラマーやライターと同様、仕事を過 
大視したり、逆に単純化したりする。マニュアル執筆者（プロのテクニカルライターも含む） 

のほとんどは、いまだに他の分野のプロに比べ、仕様書なしで仕事をするケースが多い。分厚 
い本を書くのに、ありふれたアウトライン（小学校で習った程度の方法で書かれたアウトライ 
ン）を作成するだけでは、エンジニアリングの利点を活用したことにはならない。 

•芸術家タイプとエンジニアタイプ 

図表 4.1 に見る通り、いわゆる芸術家タイプのマニュアル作成者は、プランニングという作業 
に、ほとんど重きを置かない。彼らは、まず草稿の執筆に力点を置き、その後つじつまの合わ 
ない部分に“ツギをあてること（パッチンダ)”に全精力をつぎ込む。 

また、図表 4.1 はいわゆるエンジニアタイプのマニュアル作成者が、どのように力を配分する 
かを示している。彼らの努力は、ほとんどプランニングに注がれる。つまり、どんなマニュア 
ルが必要かの定義、どんなマニュアルにすべきかという設計、マニュアルのモデル構築、といっ 
たことである。彼らにとって原稿を書くということは、企画•設計を単に実現したものにすぎ 
ず、製品の創造そのものではない。 

これら2つのタイプの間に、上記以外の違いが現われるのは、他の人がマニュアル作成に関与 
したときである。芸術家タイプは、作業が“一段落する”までは、草稿を他人に見せようとは 
しない。反対に、エンジニアタイプの手になるマニュアルは、さまざまな作成段階において、 
幅広く討議され、評価され、見直される。このため、出来上がったマニュアルには、執筆者の 
エゴが必要以上に大きく反映されることはない。 

“芸術家”という名前から、芸術家は例外なくプランニングを行なわないと想像しないで欲 
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芸術家タイフ 

労力、コスト 



作成の段階 


エンジニア タイプ 
労力、コスト 



プランニング 草稿の執筆 修正 

作成の段階 


図表 4.1 くマニュアル作成における力配分〉 

しい。また“エンジニア”という名前から、エンジニアは例外なく系統的に仕事をすると思わ 
ないで欲しい。現実には、多くのプロのライターが、草稿を書き始める前にきちんとした計画 
を立て、多くのエンジニアが、無計画な試行錯誤の中で問題を解決しているのである。もっと 
も、この試行錯誤を“プロトタイピング（試作)”と呼んで、作業を系統化しようとする傾向が 
コ ピュータ.プログラマーにはある。芸術家とエンジニアを区別しようという提案は、むしろ 
以下のことを強調することを目的としている。つまり、ある種の業務は、芸術家でもエンジニ 
アでも、どちらの“土壌”の人間でも行なうことができるが、プロジェクトが複雑になり、金 
銭的リスクが大きくなった場合、このような作業は、芸術家よりもエンジニアに任せられるべ 
きであるということである。 
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マ ー ユアルへの構造的アプロ_チ 


4.2 プログラミングの歴史から学ぶもの 


プログラミングは、私的な技能から、 エンジニア リングの正式な一分野にまで発展してきた。 
幸運なことに、プログラミングの技法を改善するために開発されてきた ほとんどすべての ツー 
ルは、マニュアルの作成にも応用できる。これらの中でもっとも重要なものは、「トップダウン 
(下方展開型）作業」と「テスト」である。 


•スパゲッティからメンテナンスのしやすさへ 

1979 年に発行された Computerworld 誌で、 Robert Perron 氏は“コンピュータが出現したこ 
ろのプログラム作成と、今日のマニュアル作成を比較してみると、非常に似ている点がいくつ 
かある’’と述べている。 1980 年代のマニュアル作成者は、 1960 年代のプログラム作成者とよく 
似ている。彼らは、ともに同じような誤りを犯しやすく、同じ精神的“土壌，，を持っているよ 
うである。このため、彼らの産み出すもの（プログラムあるいはマニュアル）は同じ欠点を持 
つのである。 

1950 年代末期から 60 年代初期にかけて、コンピュータのプログラミングは、特異な仕事、あ 
るいは風変わりな職業と見られていた。この時期のプログラマーは、その才能と情熱によって 
特徴付けられていたが、大学や他の教育機関で訓練を受けたわけでは「なく」、一般のホワイト 
カラーのようには扱われ「なかった」。彼らは、職人のように一匹狼として働いていた。彼らの 
仕事に対して厳しい管理が行なわれることはほとんどなく、彼らは予算や期限にもあまり悩ま 
されることはなかった。 

このような過去のプログラマーの作業の性質を変えたのは、何よりも次の2つのファクターで 
ある。第一は、一般的なプログラムが、1人のプログラマーの作業では間に合わないほど大規模 
なものになったことである。プログラムの巨大化が、プログラマーの自主性と優雅な孤独に終 
止符を打ったのである。第二は、プログラミングに関する費用の大部分が、プログラムの作成 
からそのメンテナンスに移行した ことで ある。そしてプログラムの大半が無秩序で、入り組ん 
でいて、メンテナンスのしにくいものである、という認識が生まれた。“スパゲッティ •コード” 
(もつれて入り組んだプログラム）という言葉が、プログラマーのスラングとなったのもこのこ 
ろである。 

一方、今日の組織では、マニュアルの「ライター」は、他のホワイトカラーと違った待遇を 
受けている。マニュアルライターは、ほとんど管理されず、予算の問題で頭を悩ますこともほ 
とんどない。たとえば、今日の多くの企業は、マニュアル1ページの執筆に対するコストを見積 
る術を知らない。 

しかし、まさに複雑さ、規模、メンテナンスといった問題によって、昔のプログラム作成手 
法が時代遅れの方法となったように、同じような問題がこれまでのマニュアル作成手法を時代 
遅れにしつつある。商品が市場に出るのと同時にマニュアルが出版されるのであるなら、マニ ュ 
アルの執筆は、スケジュール化され、予算の制約を受け、管理されなければならず、また並行 
して作業にあたれるライターのグループが 必要で ある。そして、 2、3ヶ月 ごとのシステムの 改 
訂にマニュアルも歩調を合わせるなら、変更の容易なマニュアルでなければならない。 
•プログラマーの経験から学ぶもの 

では、マニュアル作成者は、プログラマーが学んだことから何を学び取るべきなのか。まず 
第一に、ソフトウェア•エンジニアリングでもっとも大切な原則は、開発サイクルの中で問題 
の抽出が遅くなればなるほど、問題の究明と解決に要する期間と費用が、指数関数的に上昇す 
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るということである。最初のプランニング段階では2、3分、あるいは2、3ドルですむ問題解決 
が、企画•設計段階では数百倍、執筆•編集段階では数千倍、出版•運用の段階では数万倍に 
膨れ上がる。 

最初は難しいかもしれないが、プログラマーであれ、 マニュアル 作成者であれ、第一線に立 
つためには、進んで誤りを見つけ出す術を身に付ける必要がある。テストを行なわなければ、 
有用で信頼できる技術は得られない。テストの役割とは、失敗を犯させることにある。テスト 
で欠陥が見つからなければよいと思う人間、仕様書に対して討議がまったく行なわれなければ 
よいと思う人間、アウトラインに問題が1つも見つからなければよいと思う人間、これらの人々 
は、誤りの発見が遅れる（早まるのではなく）のを期待する人間で、問題の解決に結局高い代 
償を支払わせるタイプであり、品質の低下を招く連中である。 

したがって、 マニュアル 作成者がプログラミングの歴史から学ぶべきことは、以下に掲げる 
事柄を認識して、「トップダウン（下方展開型）作業」と「テスト」を実践することである。 

1. 誤りや問題の発見が早ければ早いほど、これらの修正は容易で、費用も安くすむ。マニュ 
アル作成の初期段階での作業を個人化したり、非公式化したりすると、その代価は非常に 
高くつくことになる。 

2. 入り組んだ製品のもっとも重大な問題は、これを構成する各単位やモジュールの中にある 
のではない。それらの連結および接合にある。したがって、マニュアル作成におけるコス 
卜効果を高めるには、草稿執筆前に、マニュアルを系統立てて構築しなければならない。 

また マニュアルの 各部を正しく連結する、 マニュアルの 各部において正しい筋道を立てる、 
内容に間違いがないことを確認するといったことが必要である。 

3. マニュアル作成プロジェクトが系統立てられて企画•設計されていなければ、せっかく複 
数で作業を行なっても、1人で作業をするより時間がかかってしまう場合がある。したがっ 
て、マニュアルを急いで作成するときほど、詳しく書かれ、系統立てられたモデルに沿っ 
て作業を行なう必要がある。 

4 . 複雑に入り組んだ製品やシステムを、開発の初期の段階においてぞんざいに設計してしま 
うと、メンテナンスとサポートを行なう際に、たいてい高くつくことになる。したがって、 
質が高く、メンテナンスのしやすいマニュアルを開発しようとしているときに、時間が足 
りないとか、費用が足りないとか文句を付けることは、ほとんどの場合、不当なことであ 
る。 
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マニュアルへの構造的 アプローチ 


4.3 マニュアル作成を効果的に進める5つのプロセス 


マニュアルを作成する上で必要なプロセスとは、次のようなものである。まず、本当に役に 
立つマニュアル、真に求められているマニュアルとはどういうものかをつきつめていくこと。 
次に、ジャンプ（飛越し）やスキップ（読み飛ばし）や回り道などが、なるべくないようにす 
ること。それから、明解さ、読みやすさ、信頼性などを向上させること。最後に、マニュアル 
をメンテナンス（保守）のしやすい形にすることである。 


マニュアルに関して研究室での厳格なテスト（人間の諸要素に対する心理学的分析と正式な 
テスト規約にのっとって行なわれる）を取り入れ始めている企業は、アウトラインの中の欠陥 
よりも、完成した草稿の中の欠陥の方が扱いにくいことに間もなく気付くだろう。また、プロ 
グラムのモジュールに対して単体テストを行ないながらも、テスト後のモジュールの組立てと 
統合がうまくできないという会社の場合も、同じことがいえる。これらの会社が見逃している 
ことは、書かれた後にではなく、書かれる「前」に、プログラムやマニュアルのモジュールが 
組み立てられ統合されなければならない、ということである。すでに述べた通り、マニュアル 
の執筆者と読者をもっとも悩ます問題は、モジュールやページに書かれた内容にあるのではな 
く、モジュール相互の連結および接合関係にある。 

•5 つのマニュアル作成プロセス 

マニ ュアル作成のプロセスが、過去10年間のソフトウヱア. エンジニア リングの成果から学 
ぶべきことは、以下の5点である。 

1 -ューザーのニーズと使いやすさの双方を“満たす”マニュアルを企画する。書かれるべき 
内容_マニュアルや他の情報製品の一をューザーのニーズに合致させるという方法が必要 
である。言い換えるならば、巨大な分量の1冊の汎用型マニュアルを作成するのではなく、 
特定のューザーやオペレーターの特徴と、彼らのシステムに対する使用目的に合わせたマ 
ニュアルを作成することが必要な ので ある。もっと簡単にいうならば、マニュアルと他の 
情報製品を、どのように論理的に組み合わせるのかについて定義する。つまり作成される 
文書セット全体の論理構成を考えるのである。また、こうして定義された文書セットの各 
構成要素に書かれるべき内容は、「試案としてテストできる」ものでなければならない。そ 
つすれば、計画がマニュアルやディスクに形を変える前に、作成計画に関する方針上の失 
敗が発見でき、プランを練り直すことができる。 

2 -マニュアルや他の情報製品の中の' スキップ、ジャンプ、回り道を減らす。近ごろの文書 
処理方式は、確かにテキストのさまざまなブロックを変更しやすくしてはいるが、一度 出 
来上がってしまった草稿に対して構造上の修正を加えることが困難だという事実はやはり 
否めない。したがって、修正が難しくなる草稿完成の「前」に、 マニュアル 作成における 
構造上の欠陥を明らかにする効果的な手法が何か必要である。効果的な マニュア ル作成プ 
ロセスにおいては、次第に記述が詳しくなっていく マニュアルの モデルが作られる。こう 
したモデルが作られるのは、アウトラインと草稿の間（いわゆる芸術家タイプのライター 
がたいてい1人で行なう作業期間中）であるが、このモデルについては、「有用性」という 
明確な基準でテストを行なうことができる。 

3 . ライターがチームを組んで並行して作業を行なう。不備な マニュアル に対する言い訳とし 
てもっともポピュラーなのは、 マニュアル 作成のために充分な準備をしようとすると、シ 
ステムの完成やその販売が数週間から数ヶ月遅れてしまう、という主張である。しか I 
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この主張はどう考えても、出来の悪いマニュアルが作成されたことの正しい説明にはなり 
得ない。むしろ、マニュアル作成には専門的手法が必要である、ということを示唆してい 
る。この手法とは、マニュアル執筆にチーム作業を導入し、明確に細分化されたマニュア 
ルの各部分（切身）について、「並行して」作業を行なうことである。 

しかし、用いる方法が正しくないと、ライター同士の共同作業も、マニュアル作成のス 
ピードを遅くしてしまう。間違った方法を用いると、1人で書くより2人で書く方が2〜3倍 
も時間がかかってしまう。したがって、マニュアル作成を効果的に進めるには、執筆作業 
を「独立して作業できる」単位に細分化し、これらの単位を有機的に統合する必要がある。 
このように、作業を細分化し統合すれば、コストとスケジュールをあらかじめ定めて管理 
することができる。 

もっと詳しくいうと、執筆作業の大部分を、作業量とコストの見積りが簡単にできる小 
部分に“分解”する ので ある。また、細分化された作業相互の連結および接合関係を モデ 
ルごとにあらかじめ定め、明確化し、テストすることが必要である。そうすれば、細分化 
された各部分が独立して執筆されることになり、執筆者同士が相談する必要もない。各執 
筆者は、 マニュアルの 全体 モデル さえ頭に入れておけば よいので ある。 

4. マニュアルや他の情報製品の、明確性、可読性(読みやすさ）、信頼性を高める。草稿上の 
欠陥が重大であることはもちろんである。 マニュアル 作成の目標は、草稿の出来上がる「前」 
に方針上の問題をすべて解決し、構造上の欠陥をすべて修正することにある。したがって、 
効率のよい マニュアル 作成においては、草稿が完成した時点では草稿上の問題しか残って 
いないはずである。ここで必要なのは、システムに関する不的確な表現の訂正、技術面で 
のちょっとした変更、意味の分かりにくい文節、曖昧模糊とした文章、混乱を引き起こす 
ような分かりにくいイラストなどの修正である。 

また、効果的なマニュアル作成プロセスには、編集に対する正式な基準がある。1人の人 
間の芸術的、直感的、あるいは“文体上の”嗜好には左右されない。たとえば“ F (4) を続 
けて押してください”というようなプロンプト*は、曖昧で信頼性が低い。適切なマニュア 
ル作成プロセスでは、編集者が主観的に妥当と思うか否かや、テスト段階で読者がそのプ 
ロンプトにとまどわされたか否かに関係なく、このようなセンテンスは洗い出され、修正 
される。 

5. メンテナンスしやすく、変更可能なマニュアルと情報製品を作る。出来のよいマニュアル 
は、出来の悪いマニュアルよりも修正や追加補正が少なくてすむ。ただし、修正が必要な 
ときは、修正プロセスが作成プロセスよりも簡単であることが必要で、混乱や誤った情報 
伝達を引き起こしてはならない。 


訳注*プロンプト ： prompt H 足すもの”の意）。コンピュータが、画面に表示する指示。これが表示されてい 
る間は、コマンドなどの入力待ち状態になっている。 
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第章 


作成過程の構造化:マニュ乃レ作成の 

5つのステップ 


5.1 “構造化”とは何か 

5.2 “モジュール化”とは何か 

5.3 マニュアル作成過程の全体像 

5.3.1 マニュアル作成過程におけるデータの流れ 
5.3.2 マニュアル作成過程の作業分解図 
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マニュアルへの 構造的 アプローチ 


5.1 “構造化”とは何か 


「構造化」という概念は、主に次の2つの点で マニュアル 作成に適用できる。まず第一に、 マ 
ニュアルの 開発 プロセスは “構造化 プロセス” として特徴付けられる、という点である。第二 
に、 マニュアル 自体がしばしば“構造化文書”と呼ばれる、という点である。ただし 今日、 構 
造化という言葉が、あまりに気軽に、そしてあまりに不用意に使われているということは憂慮 
すべき事態であり、どこかで歯止めをかけて言葉を正確に定義しておく必要があるだろう。 


「構造化」という言葉は、統一化、組織化といった言葉の同義語として日常会話の中でいい 
加減に使われることが多いが、むしろ私は、コンピュータ科学者やシステム•エンジニアが“構 
造化分析” “構造化設計” “構造化プログラミング”というような表現の中で使用しているのと 
同じ意味でこの言葉を使用したい。 

これら3つの用語の中では、構造化という言葉は、次のような「構造化分析」に関する定義に 
みられるある種のプロセスないし手法と深い関係にある。 

ある問題またはプロセスを公式にもとずきトップダウン（下方展開）方式で分解•分析して1つのモデルを作る 
こと（このモデルは、その問題またはプロセスの完璧で正確な記述を提供してくれる）は…プログラミングのた 
めの基礎となる… 

—Sippl and Sippi Computer Dictionary & Handbook ( Indianapolis : Sams & し o .)，1980, p . 529 

まず第一に構造化分析は優れて「形式論的」である。つまり、誰にでも理解でき、明快であ 
り、普遍的な ルールに もとづいたものである。さらにいえば、ここでいうプロセスが、もし勘 
に頼ったり、個人的なものであったり、ルールや指針を無視して進められるものであったとし 
たら、それは構造化されているとはいいがたい。 

第二にそれは「トップダウン（下方展開）的」である。つまり、できるだけ広い視野のもと 
に、あらゆるインターフェイスを含んだシステム全体としてまずとらえられ、次にある一連の 
ステップを踏んで、細部がそこに重ねられていくものである。そして、システム全体は細部の 
細かい レベルに 至るまで、その妥当性が「テスト」される。 

•解体する前に全体を見極めよ 

情報産業に携わる多くの人々は、大きな概念をより小さな概念へと分解することがトップダ 
ウン分析の本質であると誤解している。「分解」という第三のキーワードが、この誤解を産み出 
しているようである。構造化分析には、分解作業（大きなものをより小さなものへと分化させ 
ること）が付きものであるが、それにはまずシステムの全体像がどんなものかを明確化してお 
く必要がある。構造化されたテクノロジーにおいては、各部分の内容が定義される前に、各部 
分はすでに、全体の中に組み込まれているのである。 

籲モデルは製品の改良を安上がりにする 

上記の定義の中で、次にキーワードとなるのは、「モデル」である。簡単にいえば、構造化の 
方法では、まずある製品のモデルが製作され、次に製品そのものが製作される。なぜなら、完 
成された製品を改良するより、モデルを作って、それに修正を加えた方がはるかに安上がりだ 
からである。 

•ダイヤグラムとは何か 

構造化分析はこのくらいにして、「構造化設計」にいこう。 
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(構造化設計は）システムのコンポーネントと、これらコンポーネントの間の内部相互関係を、もっとも実行可能 
な方法で設計する技法である。別の言い方をすると、（構造化設計は）明確に仕様表に書かれた問題を解決するた 
めに、どんなコンポーネントが、どんなふうに内部的に相互結合されればよいかを決定する過程である。 

— Yourdon / Co . nstantine 著「ソフトウェアの構造化設計法」（日本コンピュータ協会） p . 9 


入力 

処理過程 

出 力 

項目分析 Y 
ューザー 分析」 

項目/ユーザ ー の 一 J 
マトリックス作成 

マニユアルセット 

_( マニュアル仕様書） 

マニュアル- ) 

仕様書 

► ストーリーボードの作成 H 
(“ウォークスル ー ’’） 

►マニュアル 

設計書 

マニュアル 

設計書 ~ ] 

►第一稿の作成- ) 

マニユアルの 

* 予備バージョン 

予備 - H 

バージョン H 

►技術面の見直し -H 
►文体の見直し 一^ 

►印刷済み 

マニュアル 


図表 5.1 <マニュアル作成に構造化の方法をあてはめる> 

このような方法で設計された製品には、次のような2つのものしか含まれないことに注意して 
欲しい。すなわち、コンポーネント（構成要素）とそれらコンポーネント間の相互関係、モジュー 
ルとそれらモジュール間のインターフェイス、ノー ドとエッヂ、ユニットとそれらユニット間 
の連結などである。このように構造化された製品、あるいはシステムには、2種類の要素しかな 
いため、たいていの場合、簡単なダイヤグラムで図式化することができる。このダイヤグラム 
は、モジュール（ノード、コンポーネント、ユニット）を意味する四角あるいは丸い枠と、そ 
のつながり具合い（リンク、インターフェイス、ェッヂ）を表わす矢印、または線によって構 
成される。 

繰り返すが、なぜこのようなダイヤグラムを作成するかというと一特にマニュアルのプラン 

ニンダの場合一訂正するのに手間とコストがかからないうちに、欠陥や問題点をつきとめるた 

めである。 

•構造化はコストやメンテナンスを軽減する 

開発者にとってこの手法の本当のメリットは、究極的にはメンテナンスの段階にある。なぜ 
なら、メンテナンスの段階では、モジュールやユニットの単位で置き換えや追加を行ないさえ 
すればあらゆる変更が可能であり、また、設計を綿密に行なえば、これらの変更からどんな結 
果が得られるかが予測できるからである。 

ここで強調したい点は、プログラムやシステムをコストのかからないメンテナンスのしやす 
いものにするために使われた構造化の方法が、マニュアルを考案し作成するという作業にもそ 
のまま適用できるという点である。マニュアルが構造化されれば、プログラムやシステムと同 
様、コストやメンテナンスの面で利益が得られるはずである。「作成過程」を構造化しさえすれ 
ば、そうして作られた「製品」一つまりマニュアルーも必ず構造化されるはずである。構造化 
されたマニュアルは、小さなコンポーネントやモジュールの集まりによって構成されることに 
なる。それらのコンポーネントやモジュールは、マニュアルができるだけ読みやすくなるよう 
な方法でつなぎ合わされることになるだろう。 
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5.2 “モジュール化”とは何か 


構造化システムが、分節化されたモジュールの集まりであるように、構造化文書も分節化さ 
れたモジュールの集まりである。各モジュールの出来がいいと、全体的にバラバラな感じがな 
く、先の予想もつきやすい0このようにモジュール化されたマニュアルは、設計さえしっかり 
していれば、各モジュールの組合わせが必要以上に複雑になることはない。 


一番紋切り型の定義によれば、「モジュール」とは、小型で独立していて、ある1つの機能を 
果たす単位であり、自分より大きい単位の一部をなすものである。この定義は単純すぎてかえっ 
て分かりにくい 0 モジュール化という作業は、とらえどころのない、ほとんど神秘的とさえい 
える性質のものである。設計者や技術者は、作業が煮詰まってくると、モジュール化とは何か 
を“感じる”ことはできるが、適切な言葉でそれを定義することは難しい。そこで、上記の定 
義の各部分を順番を逆にして考えてみよう。 

•モジュールはある 1 つの機能を果たす。 モジュールは自分より大きいものの単なる部分では 
ない。自分自身 [ I つの機能を果たす」。その機能が何であるかは明確に説明できる。1つのモ 
ジュールは正確にある1つの処理を実行する。その処理とは、あるデータをより有用性の高い形 
態に変換することである。さらに、よくできたモジュールは、たいてい「総体としての1つの」 
処理を実行し得る。たとえば、ある1つのファイル内の仕訳データを未払い、前払いなどに分け 
て並べ換える処理がそうである。また、モジュールの出来がよいと、処理の結果を予測できる。 
同じ条件下で行なわれた処理は、必ず同じ結果を産み出すはずであり、そのモジュールには、 
そうした入出力形式を変えるような“内部経路”はいっさい含まれない。 

•モジュールはそれぞれ独立したものである 0 各モジュールは、他のモジュールとの前後関係 
にいっさい依存しない。ある特定の機能を果たすモジュールは、他の文脈に置かれても、まっ 
たく同じ機能を果たす。ある意味では、各モジュールは、モジュールの出入れができる大きな 
セット（集合体）、あるいはライブラリの一部をなすこともある。結局のところ設計者は、手に 
入るモジュールのリストから目ぼしいものを物色し、新たに組み合わせさえすれば、システム 
や製品を簡単に構築することができる。 

•モジュールは小型である 0 上記の定義の一番曖昧な点は、モジュールのサイズに関する部分 
である。各モジュールがある1つの機能を果たすといってしまうと、モジュールのサイズを正確 
に限定することはできなくなる。結局、モジュール化されたソフトウヱアを使用する場合、あ 
る1つの機能なり概念なりが1つのモジュールに収まるか否かをいつまでも議論することは、時 
間の浪費であると覚悟せざるを得ない。そこで、構造化の方法論を用いる人々のほとんどは、 
実質的な目安として、モジュールの最大サイズをはっき0決めている。データ処理においては、 
モジュールのサイズは、たいていプログラムのステップ数によって限定される。文書作成にお 
いては、ページ数が目安となる。 

システムやマニュアルをモジュール化する醍醐味の1つは、モジュールのサイズを操作するこ 
とである。モジュールのサイズを大きくすると、各モジュールの凝集度は低く （1 つのモジュー 
ルが複数の機能を持つように）なる。逆にモジュールのサイズを小さくすると、モジュール間 
の連結や接合関係が複雑になる。モジュール化されたマニュアルでは、モジュール間の連結は、 
同じ本の違うページとの関連性として現われてくる。したがって本書の中心テーマは、 モジュー 
ルの凝集度を高める代わりに、モジュール間の連結を複雑化しないという設計方針が、使いや 

すい マニュアルの 開発に直接役立つことを証明することである。 
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マニュアル作成を上記のように取り扱う完成された方法論は、現在 Hughes Aircraft Com - 
pany で働く文書作成の専門家たちが開発した方法論に、その共通性を見出すことができる。彼 
らのやり方は、映画産業からヒントを得た“ストーリーボード作業”という形式である。彼ら 
の作る“モジュール”は、見開き1ページ（連続した2ページ）にきっちり収まるようになって 
いる。これについては、彼らの次のような草分け的な業績に詳しく述べられている。 

Tracey , J • R . , Rugh , D . E . , and Starkey , W . S . STOP: Sequential Thematic 
Organization of Publications. Hughes Aircraft Corporation : Ground 
System Group , Fullerton , CA , January 1965 

このテーマをジャーナリズムが最初に取り上げたのは、以下の中でである。 

iracey , J . R . , “The Eftect of Thematic Quantization on Expository Coher ¬ 
ence . IEEE International Convention Record ， Paper 9.4, 1966 

マニュアルのモジュール化は、マニュアルの読者にとって有益であるのみならず、設計者や 
ライターにとっても有益である。アウトラインをモジュール化（“構造化”）することから作業 
を始めることにより、設計者はマニュアルのサイズとコストを見積ることができる。さらに、 
マニュアルが正確 かつ 読みやすいものであるかどうかをテストする作業を同時に行なうことも 
できる。その上、マニュアル作成という長い複雑なプロセスを、それぞれ独立した小さい作業 
の集まりに分解して、大勢の人間に執筆の分担を割り振り、それぞれ個々に並行して作業が行 
なえるようにできる。 

マニュアルのモジュール化は、また“執筆者”にとっても有益である。この場合の執筆者と 
は、マニュアルの“原料”となるものを作成するのに必要な人々である。モジュール化された 
マニュアルの場合、これらの人々をそのまま“初稿の執筆者”と呼ぶことができる。なぜなら 
彼らは、それぞれ自分がどれだけ書き、どのようなポイントをカバーすべきかを正確に把握し 
ているからである。 

“芸術家”を自認して単独で仕事をするライターでさえ、 モジュール 化の方法から利益を得 
ることができる。彼らは モジュール1 つ 1 つに対して個別に仕事をすることができる。なぜなら、 
そうして書かれた小さい切れ切れの原稿の断片が、最終的にはうまく1つにまとまることをよく 
知っているからである。しかし、 モジュール 化の方法論から特に利益を得るのは、 マニュアル 
作成を管理する人々である。 モジュール によって マニュアルの 企画、 執筆、 編集、製作などを 
行なうと、責任者の コントロールの 質を根本的に高めることになる。 

ここでもっとも重要なことは、 モジュール 化の方法によって効果的に設計された マニュアル 
は、 ユーザー にとって考えられる限りもっとも読みやすく “親しみやすい” マニュアル である 
ということだ。事実、 モジュール 化された マニュアルを 読んだ読者は、執筆者や開発者の個人 
的な思い入れによるあらゆる論証を上回り、 マニュアル 作りの コンセプト そのものに好感を 示 
すことが多い 0 モジュール 化された マニュアルを 好まない テクニカル ライ タ ーを 私は何人か 
知っているが、それを好まない読者にはお目にかかったことがない。_ 




54 


マニュアルへの構造的アプローチ 


5.3 マニュアル作成過程の全体像 


マニュアル作成を5段階に分けると、次のようになる。1.分析（どんな情報製品が求められて 
いるかを明確に定める） 2.設計（マニュアルのモデルをいくつか構築し、それらをテストす 
る） 3.執筆•編纂（初稿をすべて書き上げる） 4.編集（“言葉のバグ”と技術的な誤りを取 
り除く） 5.保守（変える必要のある部分を変更する） 


システムを開発する上で必要なサイクルやプロセスがあるように、マニュアルを作成する上 
でも、それにふさわしいサイクルやプロセスがある。それらを以下に掲げる。 


1. 分析： ユーザーやオペレーターが、どんなマニュアルや他の情報製品を必要としているか 
を明確に定めること。システムの場合、この分析作業が、開発段階の早い時期に行なわれ 
れば行なわれるほど、明らかにそのシステムの品質は向上する。マニュアルの分析はープ 
ロジヱクトが大規模になると、出版計画の段階でようやく取り沙汰されることが多いが一 
理想的には、システムそのものの開発プランの一部として取り上げられるべきである。し 
かし、マニュアルに対するニーズの分析を行なうのに遅すぎるということはない。とにか 
く、どんなマニュアルが求められているかを分析せずに書かれたマニュアルは、たいてい 
失敗する。 


2 . 設計：マニュアルあるいは他の情報製品ごとに、詳細なアウトラインを作成すること。そ 
のための第一段階として、まず従来型のアウトラインを作成する。しかし、これはあくま 
で“構造化アウトライン”と“ストーリーボード”を作成するための1ステップである。つ 
まり、マニュアルの初稿を書く前に、テストやチヱックができるようなマニュアルの作業 
用モデルを作成するわけである。マニュアル作成の構造化や組織化を行なう上での重要な 
問題は、マニュアルの初稿が書かれる前に解決されていなければならない。 

3. 執筆•編纂： ストーリーボードを作業プランに変換し、初稿を書き上げること。マニュア 
ル作成の構造化を目指す場合、初稿を書くことは構造化プログラミングにおけるコーディ 
ング作業に少し似ている。つまり執筆者には、厳密に立てられた作業プラン（“ストーリー 
ボード”）に沿って、抜けている細部を埋めていく、という作業が最低限要求される。 

4. 編集： 明快さ、正確さ、そして“読みやすさ”、つまり、テキストを読む上での容易さ、と 
いう観点から初稿をテストすること。このステップでは、言葉遣いや文体の問題は、審美 
的な事柄とは縁遠い、ということを忘れてはならない。このステップは、むしろマニュア 
ルを使いやすいものにする、言い換えれば“失敗”させないための編集上の原則を適用す 
ることである。ここでいう“失敗”とは、オペレーターや読者が、マニュアルのバグによっ 
て、システムを操作できなくなることをいう。多くの場合、このステップの最終段階では、 
“本物の”読者に、実際にテストしてもらうことになる。 

5 . 保守 （メンテナンス）： 情報製品の中のどの部分を変更する必要があるか、また蛮更をいつ 
実施するのが適当かについて考察すること。どんなマニュアルでも（例外なく）欠点が見 
つかり、内容は色あせてしまうのである。したがって、マニュアル作成の最終段階では、 
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どの部分が追加、削除、置換え、あるいは修正の対象となるのか検討すべきである。実際、 
マニュアルの保守（メンテナンス）をうまく行なうには、まずどんな種類の変更をなすべ 
きかを知ることである。次に、読者が困惑を覚えたり、更新に付随した二重の誤りを犯さ 
ないように、変更情報をうまくユーザーに手渡し、統括管理することである。 

これら5つのステップは、効果的で使いやすいマニュアルを作る上で、ぜひとも必要である。 
これらの最初の2つ（あるいは3つか4つ）のステップを飛ばしてしまう企業は、いい加減に設計 
されたコンピュータ.プログラムやマシンの機能上および構造上のありとあらゆる欠陥をその 
ままひきずって、マニュアルを作成することになる。 

古い問題を“清算”するだけでは、マニュアル作成を効率化することはできない。マニュア 
ル作成を最後から始める一最初の作成段階でうまくいかなかった旧マニュアルを再編集するよ 
うな一方法では、まず努力はむくわれない。能率の悪いマニュアル作成過程を自動化しても意 
味がないように、ダメなマニュアルを際限なく手直ししても、時間と金を無駄に使うだけであ 
る。 



マニュアル/情報製品 


図表 5.3 くマニュアル作成のデータ•フロー.ダイヤグラム〉 
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マニュアルへの 構造的 アプローチ 


5.3 マニュアル作成過程の全体像 

5.3. 1マニュアル作成過程におけるデータの流れ 


ここに示した 5 つの図は、前ページに示したデータ •フロー. ダイヤグラムの“子供”にあた 
るものである0これらは図表 5. 3 をさらに細かく分けた 1 つ下の レベルの 図で、 5 つの段階のそれ 
ぞれにおけるデータの流れを示している。（データ •フロー • ダイヤグラムでは、データは矢印 
の方向に動き、“丸”の中に示されたような形に変化していく。） 


マニュアルの分析結果 



強制事項 


図表 5.3.1 a < 分析> 



ストーリーボード 

図表 5.3.1 b く設計〉 
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旧マニュアル内の誤り 



図表 5.3.1 d <編集> マニュアルのテスト済みパージヨン 
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マニュアルへの 構造的 アプローチ 


5.3 マニュアル作成過程の全体像 

5. 3.2 マニュアル作成過程の作業分解図 


ここでは、使いやすい マニュアル、 およびそれに関連す る 情報製品を作成す る 上で必要とな 
る作業を、ピラミッド型に階層化した簡単な作業分解図を示す。 


図表 5.3.2 b は、質の高いマニュアル作成をするために必要な作業をリストアップしたもので 
ある。また図表 5.3.2 a は、それらの作業を階層構造図で示したものである。これらの図は、あ 
らゆる作業を網羅して いる わけでは ない （たとえば、コスト評価や印刷など）が、本書の提唱 
する“構造化”の方法を実現するために必要な作業を網羅している。これらの作業のいくつか 
を省略したり、違う順序で実行しようと思うときは、それを正当化できるだけの説得力のある 
理由が必要である。 

また、この図はそれぞれの作業を誰が実行するかについては何もいっていないことに注意し 
ていただきたい。マニュアルを書いている企業や代理業者のスタッフ構成と組織体制には バラ 
エティがありすぎて、誰が何をやるべきかを指定することは不可能である。その代わり、次の 
第6章では、各作業を詳細に取り上げ、それらに必要な技術に関して、アドバイスを行なう。 



図表 5.3.2 a <マニュアル作成過程の作業分解図> 







































































作成過程の構造化：マニュアル作成の5つのステップ 


59 


図表 5.3.2 b くマニュアル作成過程の作業分解> 


(1.0) 分析：「マニュアルセット•メモ」を作る 


(1.1) システム/製品の全体像を考える 

(1.2) 対象ユーザーを考える 

(1.3) 機能、作業内容、項目などを考える 

(1.4) 「項目/ユーザーのマトリックス」を作る 

(1.5) マニュアルおよびその他の情報製品を位置付け名 

(1.6) ばらばらな「セット•メモ」を体系化する 

(1.7) 必要に応じ、プランを再検討する 


(2.0) 設計：詳細なモデルを作る 


(2.1) 従来型の（拟目別の）アウトラインを書く 

(2.2) 必要に応じて独立アウトライン（中間的なステップ）を書く 

(2.3) 「構造化アウトライン」を書く 

(2.4) 必要に応じてアウトラインを再検討する 

(2.5) 構造化アウトライン中の各項目ごとに「モジュール•スぺック」を書く 

(2.6) 必要に応じてスペックを再検討する 

(2.7) 製品のストーリーボード•モデルを組み上げる 

(2.8) モデルを最終的な段階まで見直し、テスト、改良する 


(3.0) 執筆•編纂：初稿を作る 


(3.1) 各モジュールの執筆者を決める 

(3.2) その他の分担を割りあてる 

(3.3) 初稿をコーディネートする 


(4.0) 編集：初稿を編集する 


(4.1) 明確さと読みやすさのために編集する 

(4.2) 技術的な正確さのために編集する 

(4.3) 初稿の有用性を確認する（実際のユーザーにテストさせる） 


(5.0) 保守：マニュアルをサポートおよび更新する 


(5.1) マニュアルおよび他の情報製品のバグを取る 

(5.2) 製品のバージョンアップを検討する 

(5.3) マニュアルの八ージョンアップを検討する 

(5.4) メンテナンス用の情報製品を出荷する 
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第^ 5 章 

分析:どんなマニュアルが 
求められているか 


6-1 マニュアルはユーザーサポートの一形態 
6.2 プロジェクトチームを組織する 
6.3 機能と項目をリストアップする 
6.4 対象者を分析する：ユーザーと読者 
6.5 項目/対象者のマトリックスを作成する 
6.6 分化：境界部分と重複部分を分ける 
6.7 マニュアルセット•メモから 
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マニュアルへの 構造的 アプローチ 


6.1マニュアルは ユーザーサボー トの一形態 


マニユアルの中身を決める場合、そのマニユアルが含まれる文書や情報製品のさらに大きな 
セットを定義しておかなければ、解決できない基本的な問題がいくつかある。 


•森を見てから木を見るべし 

マニュアル作成を開始する際に正しい方針を立てようとするならば、そのマニュアルを含む 
情報製品の「全体像」（マニュアル、リファレンスカード、ビデオテープなど）を明確化するこ 
と、そして各情報製品が全体の中でどのような機能とどのような守備範囲を持つかを、明確化 
することが必要である。なぜなら、事柄 T を明確に定義するためには、事柄 T に含まれないこ 
とを明確に定義しなくてはならないからである。マニュアルの目的を明らかにするには、マニュ 
アルを他の近接関係の文書と対置させるという方法が、もっとも確実である。 

ある問題を解決する糸口の1つは、その問題をより大きな問題の一部と見ることである。マ 
ニュアル A に何を書くべきかを知るためには、そもそもなぜマニュアルというものが（それも 
複数の）必要なのか、それら複数のマニュアルは全体としてどんな機能を果たすのか、その全 
体の中で個々はどのような働きをするのか、ということを知る必要がある。 

実際、複数のマニュアルの全体像を明確に定義する最善の方法は、マニュアルをより大きな 
総体（いわゆる「情報製品」と呼ばれるもの）の一部とみなすことである。その総体には、マ 
ニュアルのみならず、オーディオビジュアル製品、オンライン•チュートリアルなどをはじめ、 
ューザーの教育や情報参照を目的としたあらゆる領域のメディアが含まれる。 

さらにいうならば、ューザーにとって必要な情報製品の全体を明確化するには、ューザーサー 
ビスの全領域を加えた、さらに大きな総体である「ューザーサポート」を考え、この一部に情 
報製品があると考えるのが、もっとも適切な方法である（図表 6.1 参照）。 

また、 情報製品の必要量とューザーサービスの必要量には、交換可能な関係がある ことにも 
注意して欲しい。情報製品が高品質であれば、トレーニング、コンサルティング、メンテナン 
スなどの必要性を引き下げることができる。実際、これらのューザーサービスとマニュアルの 
品質とのバランスが、マニュアル作成にかかる費用の多寡を決める主要な評価基準となるので 
ある（つまり、マニュアル作成にいくら費用をかけても、ューザーサービスを軽減しないよう 
なマニュアルでは、その費用は無駄ということになる）。 

簡単にいうと、ある1つのマニュアルの守備範囲を決めるのは、アウトライン作成時でも、も 
ちろん初稿執筆時でもなく、アウトライン作成の「前」である。また、誰がどんな情報を必要 
としているかについての議論は、マニュアル作成作業の最初に行なわれ、2冊のマニュアルの内 
容が重複しないかという議論は、双方のアウトラインが書かれる前に行なわれる。 
•マニュアルの問題は書く前に発生する 

こうした根本方針の重要性に気付いていないはずはないのだが、いまだにほとんどのマニュ 
アル執筆者は、この問題に真剣に取り組もうとしない。プログラムを書きたくて仕方のないプ 
ログラマーのように、マニュアル執筆者はテキストを書くことに入れ込んでしまう。書き始め 
る前にマニュアルの守備範囲を議論するよりも、とりあえず書き始め、後になってそのマニュ 
アルがある特定の読者に役立つかどうかと悩んでしまうのである。 

しかし、結局は読者を無視していることと同じになってしまう。書き上げられた草稿は、コー 
ディングが終わったプログラムと同様に、口出しをはねつけるものとなってしまい、執筆者は 
草稿の守護者となってしまう。すでに執筆が完了し、金額が算出されたマニュアルを前にすれ 
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ば、ユーザーや消費者のニーズなどは、ほとんど影響力を持たないのである。明確な定義が行 
なわれず、誤ったコンセプトの下で作成作業の開始されたマニュアルに、今日も多くの熟達し 
た執筆者が悪戦苦闘している。不幸なことに、これらの執筆者は、マニュアルの「内容」に問 
題があると思っているが、実はマニュアル作成の方針に問題があるのである。つまり、情報製 
品に対するプランが、策定されていないということである。 

有能なライターに悪いマニュアルを書かせることほど、無益なことはない。 したがって、マ 
ニュアルとは何かを明確にし、何を書くべきで、何を“書いてはならない”かを知るための唯 
一の方法は、情報製品を1つ1つ取り上げて、全体像における他のものとの違いをはっきりさせ 
ることである。 




ュー ザー 
サービス 


r 


印刷物として 
のマニュアル 


1 


“印刷物以外” 
のマニュアル 
(オーデイオ、 
オンライン他） 


トレーニング 


コンサル 
テイング 


訪問 

メンテナンス 


図表 6.1 くユーザーサポートにおけるマニュアルの位置> 
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マニュアルへの 構造的 アプローチ 


6.2 プロジェクトチームを組織する 


まず最初にやらなければならないことは、マニュアル作成のプロジヱクトチームを組織する 
ことである0このプロジェクトチームの任務は、簡単にいうと、対象となるシステムにどんな 
マニュアルが要求されているかを討議し、マニュアルセット.メモ（マニュアルの企画案と、 
その簡単な内容説明をリストアップしたもの）を用意することである。チームの運営を成功さ 
せるには、まず、技術関係の専門家、次にその技術を利用する側の専門家、そして両者のまと 
め役としてのコーディネーターが必要である。 


作成すべきマニュアルの方向を定め、その内容を説明する任務にあたるチームが組織されな 
い限り、マニュアル作成の諸問題に取り組むことはできない。 

「どんなマニュアルが必要か」を決めることは、不用意になされたり、熟慮せずに行なわれ 
たりするには、あまりにも重要すぎる問題である。同じように、1人の人間が決定するのにも重 
大すぎる。そこで、どのようなマニュアルが求められているかを決定するには、少なくともマ 
ニュアルに対する次の3部門からの見方が必要となる。 

• 技術面の専門家 
• 利用面の専門家 
•統合管理面の専門家（審判員） 

•技術面の専門家は、 システムの設計や内部構造について、熟知している人物である。システ 
ム •アナリスト、 主任デザイナーや開発 員、プロジェクト•マネジャー、 あるいは エンジニア 
本人などがこれにあたる。こうした技術面の専門家は、システムの側に立って発言しなければ 
ならない。システムがほとんど完成している状態なら、技術面の専門家はその機能および特徴 
について一番よく知っている人間のはずであり、システムが開発途上の場合は、その機能仕様、 
あるいは全般的な設計を担当しているはずである。 

參利用面の専門家 （“ ユーザー” と断定してもかまわない） は、 システムのもたらす利益を知っ 
ていなければならない。 ユーザー、 エンド ユーザー、オペレーター、 工場関係者、熟練作業員、 
監査役、マーケティング•マネジャー、トレーニング担当者、顧客管理係などが、これにあた 
る。これらの人々は、誰もがプロジヱクトチームの参加メンバーとして最適任といえるだろう。 
利用面の専門家の任務は、チームのメンバーに対して、機会あるごとに、「システムは使用され、 
操作されなければならない」ということを、想い起こさせることである。 ユーザー や オペレー 
ター（取締役や経営者、あるいはセールスマンも含む）とは、システム内部の働きにほとんど 
興味を持っていない人々、技術面の知識をほとんど、あるいはまったく持っていない人々であ 
り、システムが何をもたらしてくれるかについて、ほとんどつねに過剰の期待を持っている人々 
のことである。 

•ほとんどの場合、これら2方向からの見方は衝突する 。たいていユーザー側が論争をしかけ、 
アナリスト側がそれに応戦するということになる。したがって、 チームの 第三の メンバー、 す 
なわち統合管理 面の 専門家（コーディネーター）が意見の衝突をうまくさばき、双方から合意 
を引き出す役割を担う。ドキュメ ンター （あるいは“ドキュメンタリスト”）、“ ビジネス•シ 
ステム•アナリスト”、渉外担当員、品質検査員、テクニカルライター、あるいは出版技術の専 
門家などが、これにあたる。統合管理面の専門家は、実際的なメモやリストを作成しなければ 
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図表 6.2 <マニュアル作成プロジェクトチーム> 


観点 

メンバー 


• 技術面 

• システム•アナリスト 

• 主任デザイナー/開発員 
. ブロジエクト•マネジャ 
•ハードウエアの 1 ， V : 門家 
• ソフトウエアの専門家 

一 

• 利用面 

. ユーザー • 

. オペレーター • 

• 工場関係者 • 

• 熟練作業員 • 

監査役 

マー ケ ッ ター 

ト レーニン グ 担当者 
顧客管理係 


• 統合管理面 


ドキ ュメン ター/エディ ター 
ビジネス•システム•アナリスト 
渉外担当 員/コーディネーター 
品質検査係 
テクニカルライター 
出版技術の専門家/マ ネジャー 


ならない。彼または彼女は、双方の意見を注意深く聞き、今後話し合われる事柄について、そ 
の進むべき方向を管理する人々であり、対象となるシステムに関するマニュアルセット•メモ 
を作成する人々である。 

•メンバーのバランスは取れているか 

このようなプランでマニュアル作成を行なうと、マニュアル作成の責任者は、マネジャーや 
コーディ ネーターとなることに注目して欲しい。彼らはプランニングの初期の段階から參加し 
ている メンバー であり、乱雑な初稿を整理する コピー•エディター ではないのである。また、 
マニュアルの必要性を定義するという仕事は、技術面の専門家、あるいは利用面の専門家のど 
ちらか一方に任せられるものではない、ということも忘れてはならない。なぜなら、この2種類 
の専門家が相手の意見を尊重することなど、ほとんどありえないからである。実際の作業では、 
この2者間の コミ ュニ ケーショ ンが、非常に難しい場合が多い。 

理想的には、チームは3人のメンバー（各部門から1人ずつ）で構成されるべきである。シス 
テムが非常に複雑な場合、あるいは対象ユーザーが普通以上に多方面に渡っている場合などは、 
メンバーはもう少し多くなるだろう。しかし、注意して欲しいことは、もし技術面か利用面の 
どちら かの 専門家が複数いると、そちらの勢力が勝ってしまう、ということである。たとえば、 
ハードウヱアとソフトウェアの専門家が複数いる場合には“システムのもたらす利益”に立っ 
て発言する人間も複数必要である。それができない場合は、特定の技術分野の専門家がマニュ 
アルの内容とは無関係な記述を挿入しないよう、コーディネーターはつねに注意を払わなけれ 
ばならない。 

また2人だけのプロジェクトチームにも用心しなければならない。“能率アップ”を考えて、 
有用な論争を避けてしまうからである。特に用心しなければならないのは、マニュアルの必要 
性を定義する仕事が、たった1人の人間に任される場合である。 
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マニュアルへの 構造的 アプローチ 


6.3 機能と項目をリストアップする 


技術者がチームの中で果たす役割は、システム構成•機能などの「項目」をリストアップす 
ることである。これらは、マニュアルにどうしても書かなければならない事柄である。確かに、 
システムのあらゆる側面を分類するには、無限の組合わせが存在するが、業務内容別の分け方 
が最適ではある。しかし、マニュアルの内容分析を完全で、より詳細なものにするためには、 
ある特定のアプローチに重きを置きすぎるべきではない。 


ある製品にどんなマニュアルが必要かを分析する場合、まず最初にやらなければならない作 
業は、どんな製品かを明確に定めることである。いわば、その製品の商品価値を判定すること 
である。 

•分解作業のさまざまな観点 

項目の分析（あるいは機能分析）は、プロジヱクトチームにおけるシステムの専門家の仕事 
である。この分解作業は、チームの他のメンバーからも当然影響を受けるが、システム自体の 
構造や形態を説明するのは、やはりシステムの専門家の仕事である。 

システムは、ハード構成、設計、テクノロジー、オペレーション（操作方法)、アプリケーショ 
ン（適応業務)、あるいはューザーの利益など、さまざまな観点から説明され得る。 

図表 6.3 a は、ハード構成およびそれに付随する事柄の面から、システムを分解した一部であ 
る0このような分解作業は、システム•プランニングの一環として、すでになされていること 
が多い。 

さらに、他のアプローチとして、アナリストや エンジニアに とってはやや畑違いかもしれな 
いが、図表 6.3 b のように、販売戦略、あるいはシステムが ューザーに 与える利益という観点か 
らシステムを分解する方法もある。 

•業務別マニュアルとは何か 

1980年代においては、マニュアル作成班の間で「業務別マニュアル」についての討議が、か 
なり多くなされている。業務別とは、対象読者が実行する業務に合わせて、マニュアルが組み 
立てられているということである（図表 6.3 c 参照）。この業務別（製品別と対比されることが多 
い）とは、技術インストラクターが“スキル分析*”と呼び、一部の社会学者たちが“作業評定*” 
と呼んでいるものに相当する言い方である。簡単にいうと、業務別のマニュアルとは、ューザー 
の行なう業務だけをサポートし、システムの特性に関する一般的な説明を控えたものである。 
さらにいうと、こうした考えに関する IBM バリアント*では一 ITCC * の最近の会合において提 
示された多くの報告書にも紹介されているが一“一般業務体系*”（考えられる限りのあらゆる 
業務と、あらゆるソフトウヱアやシステムに関する標準分類表）を作成しようという試みがな 
されている。 

今後さらにはっきりとした傾向になるとは思うが、マニュアルから逆戻りや回り道をなくす 
ための最善の方法ーマニュアルの有用性を高めるために一は、 はっきりと定められた対象者に 
向けて、業務別のマニュアルを作る ことである。ただし、項目の分解作業が、最初から業務別 
に行なわれ「なかった」としても、マニュアル作成の後の段階で、このアイデアを組み入れる 
機会は、まだあるのだということに留意していただきたい。 

•どこまで分解すべ吉か 

機能および項目を定義する上で、業務別という分解作業の他にも、さまざまな分け方がある。 
マニュアルを作成する場合、業務別の分解作業は、ハード面での分解作業より便利であること 
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• デバイス 
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図表 6.3 a <ハード構成別項目リスト> 


キーボー ドの再定義 

ユーザー登録用ファンクションキー 

出力形式ツール 

“マクロ定義* *”のできるワープロ 
機能 


製品の選択/評価 
プランニング/設置準備 
インストール 
ハード構成登録 
カスタマイジング/初期値設定 
ァプリケーション（適応業務）の記述 
トラブル対策/メンテナンス 
ファイル•コンバート 
キーボード*テンプレートの作成 
他のシステムとのデータ交換 


図表 6.3 b <販売戦略/利益別項目リスト > 図表 6.3 c <業務別項目リスト> 


が多いが、どんな分け方を用いるにせよ、充分な分析がなされるまでは、続けられるべきであ 
る。 

果たしてどこまで続けられるべきか。プロ ジヱ クト チームのメンバーが、 次のような全体的 
な質問に答えられるようになるまで、項目は細分化されなければならない。つまり、「項目丁は 
読者 R にとって必要か」という質問に、「必要である」あるいは「必要でない」と明確に答えら 
れるようになるまでである。項目の定義が、大ざっぱであったり、曖昧であったりした場合は、 
もう一度分析をやり直さなければならない。 


原注*スキル分析：ある修学課程や学習プログラムにどんな項目を含めるべきかを明確に定義する方法。主に 
学生や学習者がある作業を遂行するのに必要とする知識や能力を基準としている。 

* 作業評定：人間の行なうあらゆる業務を観察し、記録する方法。考えられる限りのあらゆる行為および 
相互行為を書き込んだ分類表を使用して行なわれる。 

* IBM バリアント： IBM が開発中の、業務別マニュアル作成のための特別な手法。 

* ITCC : International Technical Communication Conference 。 アメリカの Society for Technical 

Communication がスポンサーになっている年 1 回のシンポジウム。 

* 一般業務体系： IBM の開発した作業評定表で、ユーザーが自分の仕事を遂行するのにどんな文書を必要 
とするかを分析するのに利用される 。 IBM Publication Guidelines : Designing Task-Oriented 
Libraries for Programming Products を參照（注文番号 ZC 28-2525) 

訳注*マクロ定義：長い操作手順を2〜3のキー操作でできるようにする機能。 
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6. 4対象者を分析する：ユーザーと読者 


どんなマニュァルが必要かを定義する上で中心となる課題の1つは、マニュアルの対象者（シ 
ステムに関する情報を必要としているユーザーおよび読者の層）を分析することである。対象 
者に関する分析や階層化は、プロジェクトチームの中で、ユーザーやオペレーターにあてたマ 
ニュアルの部分を担当する者、あるいはシステムの使われ方に関する専門家としてチームに参 
加している者にとっての責任である。 


•使用目的と経験で読者を分ける 

「読者」をその使用目的と経験によって位置付けられるものとして定義しよう。2人の読者が、 
あるシステムに関し、共通の使用目的および共通の技術的（職業的）経験を持っていた場合、 
彼らは同じ読者層をなす。そのシステムに対し異なった使用目的（つまり異なった役割、異なっ 
た適応業務など）を持つ人々は、異なった読者層に属する。同様に、異なった技術的経験を持 
つ人々は、たとえ同じ目的でそのシステムを利用するとしても、異なった読者層としてみなさ 
れるべきである。 

ユーザー層の広がりは、製品および システムの すそ野の広がりに対応している。そして、最 
新の読者層は、 コンピュータ • テクノロジー に関する技術的経験をほとんど持たない人々に、 
ますます広がる傾向にある。 

とはいっても、ユーザーおよび読者を分解する作業は、やり過ぎないことが肝心である。問 
題になっているユーザー層を明確化する上で、せいぜい3つから10個のカテゴリーに分けるのが 
普通である（図表 6.4 の分解図は、10個のカテゴリーに分けられた場合のよい実例である）。も 
ちろん例外的に、読者層が10以上のカテゴリーに分けられるシステムもある。読者層は、少な 
く見積るよりも多く見積った方がよい。なぜなら、分析の後の段階において、余分で不必要な 
カテゴリーは、削除することができるからである。 



図表 6.4 <対象読者を分析する〉 
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まず最初の分解は、仕事の専門分野あるいは肩書によって行なわれる（厳密にいえば、同一 
の経験および使用目的を持つ人々は、まったく別の肩書を持っている場合でも、同じ読者層に 
入る）。さらに、最初の分解で得られたカテゴリーの中で、経験の有無を基準として、さらに2 
回目の分解を行なう。マニュアル作成においてありがちな問題は、経験豊かなベテランと、こ 
れから練習しようという初心者の両方を対象とするマニュアルを書いてしまうことである。彼 
らには、同じ職務が割りあてられることもあり得るため、両者を対象とするマニュアルは、「帯 
に短したすきに長し」となってしまう。したがって、1回目の分解で得られた職業的カテゴリー 
に対して、経験の レベル、 あるいは経歴の違いを基準として、さらに分解作業を行ない、サブ 
グループ化することが賢明である。 

• 3 つ目の基準：神経質 

特に、 ユーザー や オペレーターにシステムの 働きを説明するために マニュアルを 作る場合な 
ど、読者を定義する上で、「神経質」という基準による第三の分解作業が必要になってくるだろ 
う。 

この神経質という基準は、たいてい経験の不足や技術的訓練を充分受けていないことと密接 
に結び付いている。したがって、対象者の分解作業を行なう上で、あえてそれを考慮に入れる 
必要はない。しかし、たとえば“高校出のキーパンチャー”と呼ばれる読者が対象となってい 
たら、ほとんどの読者が、システムに対し、神経質で自信がないと予想することができる。ま 
た、あるシステムを CAD (コンピュータ援用設計)用に使用している技術者グループが読者だっ 
た場合、彼らのほとんどが自信を持っており、システムやマニュアルには、むやみに神経質に 
ならないと予想することができる。 

読者の分解作業は、重要な課題である。マニュアルを、読者全般を対象とする分かりやすい 
説明書として作成することは、方針上の深刻な誤りである。この分解作業において大切なこと 
は、 オペレーター、マネジャー、プログラマー など、システムに接しようとするあらゆるユー 
ザーに対して、彼らが本当に欲しているマニュアルを、確実に提供できるようにすることであ 
る。さしあたりここでは、ユーザーと読者をできる限り細かく分解するという“もっとも初歩 
的なケース”で充分である。どんなマニュアルが求められているかについて決断を下すには、 
誰がなぜ、そのマニュアルを求めているのかについて、まだまだ熟考しなければならないから 
である。 
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6.5 項目/対象者のマトリツクスを作成する 


2つの分解作業をもとに、プロジェクトチームのマニュアル•コーデイネーターは、項目/対 
象者のマトリックスを作成する0次にチーム全員で、マトリックスの縦と横にどういう接点が 
あるかを分析する。この接点は、どの項目がどの対象者に対応しているかを表わしている。 


•どの項目はどの読者のために7 

プロジヱクトチームは、項目と読者に関する2つの分解図を読者/項目のマトリックスに書き 
換える。そして、どの項目がどのユーザーの使用目的に合致するかを判断する。 

この判断に ついて、 プロジヱクト チームの 意見が対立することはまれである。意見の不一致 
があった場合、一番簡単な打開策は、とりあえず、問題の項目もマトリックスに含めておくこ 
とである。（どんなマニュアルが必要かについての選択を行なう場合、もっとも無難なやり方は、 
情報を切り捨てるよりも、余分に取り入れておくことである）。 

図表 6. 5において、各項目は「必要である」あるいは「必要でない」と明確に答えられるまで 
細分化されている。つまり、特定の読者がその項目の全体を知る必要があるかないかが判断で 
きるまで、細かく分けられているのである。 

おもしろいことに、この種のマトリックスは、企業の従業員研修部門で作成されているもの 
に類似している。それは“スキルマトリックス*”あるいは“タスクマトリックス*”と呼ばれ、 
さまざまな従業員の訓練事項の要否を決定するのに使われている。もし、会社の研修部門で、 

この種の分析がすでになされていれば、マニュアルに何が必要であるかを分析する上で、それ 
らのマトリックスが役に立つだろう。 

•マトリックスから読み取れるもの 

このマトリックスで、 何が分かるだろう か。マトリックス 作成は、 プログラマーのいらいら 
を募らせ、プログラムの 再検討を促すような手間のかかる作業のように思えるが、実はまった 
く逆である。 

表の中でチェックマークの付けられた部分は、さまざまなマニュアルの形態を暗示している。 
マトリックスを作成しないと、出来の悪いマニュアルが作られてしまう可能性が高くなる。 

マトリックスは、シンキング•ツール（考えるための道具）である。もし、チェックマーク 
の付いていない項目があったら、対象者に含むべき読者をぬかしている可能性を考慮しなけれ 
ばならない。また、チヱックマークの付いていない読者がいたら、その読者に必要な情報が抜 
け落ちているということである。 

さらに、このマトリックスは、違った使用目的を持っていると予想される人々が、非常に似 
通った情報を必要としていることも示してくれる（たとえば、データ管理部門の責任者とデー 
夕入力係については、しばしば似たようなチェック結果が現われる）。もっと大切なことは、あ 
る読者が無視されている、不適当な情報に惑わされる可能性がある、振り回される恐れがある、 
まったく違った情報を必要としている読者と同一視されている、といった事柄がおのずと判明 
することである。 

この長い項目のリストを、マニュアルの記述内容の在庫目録として考え、読者層のリストを 
この記述内容の消費者と考えて欲しい。そうすれば、項目/対象者のマトリックスの最終目標 
とは、在庫の中から、消費者の便宜と必要性に合わせて、どのように情報を提供したらよいか、 
その「在庫仕訳」の方法を決定することになる。 
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項目/対象者マトリックス（「生産計画システム」の場合） 
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図表 6.5 < 項目/対象者のマトリックス> 


原注* *スキルマトリックス：修得すべき技能を縦にし、教育の対象となる学習生のグループを横にした表。 

* タスクマトリックス：説明すべき（マニュアルに記述すべき）業務を縦にし、ユーザーや得意先のグルー 
ブを横にした表。 
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6.6 分化：境界部分と重複部分を分ける 


プロジェクトチームは次に、項目と対象者のマトリックスを検討して、そこから、いくつか 
のパターンやグループを洗い出し、それによってマニュアルを区分けする0分化された一方の 
極においては、1冊に収まった事典的な汎用型のリファレンス•マニュアルが考えられる0その 
際、マトリックスの項目は、そのまま読者のためのインデックス（索引）になり得る。またも 
う一方の極では、各対象者あるいは項目ごとに、いくつかの分冊に分けられたマニュアルが考 
えられる。この両極間のどこかに解答があるはずだ。つまり、マニュアルの理想的な分化は、 
下図に示したような、双方の折衷案によって決定することができる。 


システムの中に境界線をひくのと同様、マニュアルに境界を定める場合にも、多くの決定と 
トレードオフが一たいてい独断的に一なされる。 

プロジェクトチームのメンバーが、マニュアル、オーディオビジュアルおよび他の情報製品 
のもっともコストパフォーマンスのよい組合わせを考える場合、さまざまな要因が互いにせめ 
ぎ合う。もちろん、企画したもの以外の情報製品を作る会社はほとんどないので、マニュアル 
全体は、汎用型（百科事典型）の極に傾く傾向がある。 

•対象者別マニュアル 

図表 6. 6に見られるように、2つの方針には、それに有利に働く特徴と不利に働く特徴がある。 
対象者別のマニュアルには、意思伝達の上で多くのメリットがある。10以上の読者層がそれぞ 
れ選択できるマニュアルのバージョンがあるといっても決して過言ではない。それは結局、読 
者の使用目的にぴったり合致したマニュアルに行きつくことになり、他のマニュアルへの参照 
や迂回の道からわれわれを解放してくれる。この方針では、マニュアルは薄めになり、オー 
ナーシップー全員が同じバージョンのマニュアルを持っていたら持ち得ない感情一に裏付けら 
れた威信を持つことさえできる。 


〇対象者別マニュアル 

汎用型マニュアル〇 

• ユーザー特注 

•効率的、冗長的ではない 

•理解しやすい、簡潔 

• プランニングを簡単にする 

• 個々のユーザーに親しみやすい 

•製作作業を簡単にする 

• 安全性を確保する 

• メンテナンスを簡単にする 

• 濫用を避ける 

• 技能習得にも使える 

• トレーニング•マニュアルの役割を果たす 

• ユーザー間のライバル意識を排除する 

•経費を節約できる（場合に応じて） 

• よいオンライン • システムをもたらす 

•メンテナンスを複雑にする 

•厚く重い本 

• ユーザーを過小評価する 

• ユーザーに圧迫感を与える 

• 技能習得を妨げる 

• トレーニング担当者やサービス要員に重荷となる 

•経費がかかる（たいていの場合） 

•複雑な索引を必要とする 


図表 6.6 <マニュアルをタイプ分けした場合の両極> 
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各対象者にあてられた薄いマニュアルは、またある種の読者が手に取るのを制限することに 
よって、安全性を確保することにもなる。同じように、オペレーターやューザーが、使い方の 
まだよく分かっていない操作や機能を試そうとするのを防ぐ役目も果たしてくれる。場合に 
よっては、さまざまなバージョンのマニュアルを作ることは安くつくことさえある。われわれ 
はときどき、薄いマニュアルの コピーを 100部あるいは、1000部取る必要に迫られるが、厚いマ 
ニュ アルを コピーす る必要はあまり出てこない。 

しかしながら、対象者別のマニュアル作りはたいていの場合高くつき、メンテナンスも非常 
に難しくなるだろう。明らかに、1つのバージョンだけ（そのマニュアルの他のもろもろのバー 
ジョンは放っておいて）バージョンアップを継続的に行なう、ということは難しい0対象者別 
のバージョンはまた、対象となる読者の能力を過小評価したり、彼らの実力を向上させるよう 
な技能の習得を妨げたり、他のさまざまなマニュアルを参照させるような事態も引き起こす。 
•汎用型マニュアル 

ほとんどのマニュアル作成者は、作ろうとするマニュアルのニーズを対象者別で分析しよう 
とはしない。むしろ彼らは、マニュアルを「1つのまとまり」、著述およびデータの1ファイルと 
考えている。このような汎用型のマニュアルを選ぶことが正しい場合もある。つまり、同一の 
層に属するューザー向けの簡単なシステムの場合には、1冊のマニュアルが一番よいだろう。し 
かし、 マニュアルを1冊にすることは、読者にとっての使いやすさをあまり考慮せずに、マニュ 

アルの作成プランを単純化し、短期コストを低下させるための便宜上の方法であることが多い。 

しかも、汎用的な マニュアルで まかなおうとする 会社の 多くは、インデックスを付けることを 
怠りがちである。百科事典に、索引もクロスリファレンスの方法も用意されていなかったとし 
たら、読者がそれを使用することはほとんど不可能である。かといって、それがすぐに複数の 
マニュアルの 方がよいということにはつながらない。 

マニュアルを 作成する上でのもっとも興味深いパラドクスは、事典のような汎用型 マニュア 
ルー大多数のューザーにとって、もっとも厄介でなじみにくい一が、 マニュアルの オンライン • 
システムにとっては、理想的であるということだ。難しい検索ルーチン、クロス リファレンス 
や回り道、不必要な部分のトリミング、その他もろもろの処理をしなければならないのは、ュー 
ザーではなく、システムの方である。検索プログラムは、読者にとっては“透過的*”である。 
これは、コンピュータ用語でいうところの“不可視的”に等しい。 


訳注*透過的： transparent。 通常の英語では「透明な、明白な」という意味だが、ここでは中身が見透せると 
いう意味ではなく、ユーザーが知らず知らずのうちに検索プログラムに入り、知らず知らずのうちに 
出ることができる、つまりユーザーが“意識しなくともよいもの”という意味で使われていると思わ 
れる。 
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6.7 マニュアルセツト•メモから 


プ ロジェクト チームの討議の結果をもとに、 「マニュアル.コーディネーター」は、上層 部の 
承認を 受けたプランに 関するメモを作成する 0 そのプランには、 マニュアル および他に開発の 
予定されている情報製品の概略が盛り込まれている。 


プロジヱクトチームは、マニュアルセット•メモを作成し、配布する。このメモには、シス 
テムのライフサイクルの最後（システムがお払い箱になる時点）までに書かれるあらゆる文書 
に関するプランが盛り込まれる。言い換えれば、長い射程で見た標準的なマニュアル•セット 
の中から、現在進行中のプロジェクトにあてはまるマニュアルを選ぶわけである。 

マニュアルやその他の情報製品に関し、次のようなことがメモに書き込まれる： 

•表 題ーマニュアルの詳しい名称。そのマニュアルの守備範囲と対象ユーザーが分かるよ 
うな表現にする。 

•コード番号一 関係者全員が、マニュアルの進行と コスト を管理できるように付けられた コー 
ド番号。 

•メディアー 情報の伝達形態。そのマニュアルは書籍なのか、もしそうなら形式と材質はどの 
ようなものか（たとえば、ルーズリーフ•バインダーなど）。さもなくば、書籍以外のメディ 
アが使用されているのか（たとえば、ビデオ、ポスター、プレースマットなど）。 

籲読 者一対象となる読者の職業上のカテゴリーに関する簡単な記述。分かっている場合に 

は、特定の組織、団体、個人の名称も。 

•優先順位一同ーセット内のすべてのマニュアルに関する相対的な重要度の目安。特に、同一 
セット内の各マニュアルに割りあてられた人員や資材が不足しそうな場合などには、重要な 
役割を果たす。 

籲 完成日ーマニュアルの完成予定日。プロジヱクトが大きい場合には、いくつかのマイルス 
トーン*でもよい。たとえば、ストーリーボード、第一稿、“実際のユーザー”によるテスト、 
最終デザイン、印刷など。 

籲 責任者ーマニュアル作成を予定通りに、仕様書通りに、そして予算の範囲内で進めるべき 
人。この責任者が決定するまで、マニュアルは書き始められるべきではない。“ライター”の 
肩書は、責任者の仕事を意味しないことに注意すること。実際、ライターの1人が責任者にな 
ることは避けるべきである。 

•予 算ー プロジェクトにあてられた人件費、その他の予算に関する記述。明細は必要に応 

じて。マニュアル作成は確かに高くつくが、システム開発の他の側面と一緒に、開発コスト 
として“ひとまとめ”にしてしまうのには無理がある。 

図表 6. 7は、項目の書き込まれたマニュアルセット•メモの一部である。これは、分析作業の 
段階のアウトブットであり、設計作業の段階へのインプットである。どのようなマニュアルが 
要求されているのかについて、充分検討した後でなければ、マニュアルのアウトラインを書く 
べきではない。 
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表題： 生産計画システム用明解ユーザー•ガイド 

メディァ： ルーズリーフ コード番号： PS — 01 優先順位 ： a 

読者： 生産部門；品質管理部門；保安部門 
責任者： ヘミングゥヱイ 完成日： ’ 8 5. 3 

七クシヨン/内容 

ブラン、利益、準備/導入、データ入力、報告書、分析、 

グラフ化、エラーとプログラムの サービス、リファレンス•ツール 

予算： 3 0 , 0 0 0ドル（人件費）； 7, 0 0 0ドル（製作費） 

表題： 生産計画システム用オペレーシヨン.マニュアル 

メディァ： ルーズリーフ コード番号： PS -0 2 優先順位 ： A 

読者： データ入力係（経験者） 

責任者： スタインベック 完成日： ，85.3 

七クシヨン/内容 

導入、カスタマイジング、初期設定、データ入力、レポート作成、 

グラフ作成、エラー、リファレンス 

予算： 9 , 0 0 0ドル（人件費）； 2 , 0 0 0ドル（製作費） 

表題： 生産計画システムを使つた応用例題集 

メディァ： スパイラルバインダー コード番号： PS -0 3 優先順位：旦 
読者： 技術部門 

責任者： カンディンスキー 完成日： ， 85.5 

セクシヨン/内容 

伸び率グラフ、予想グラフ、コスト•グラフ 
予算： 1, 5 0 0, 0 0ドル（人件費）； 5 0 0ドル（製作費） 

図表 6.7 < マニュアルセット • メモの記入例> 


訳注*マイルストーン： milestone 。 プロジェクト•マネジネントの用語で、期間（日数）がゼロの作業。プロジェ 
クトの進行状況を監視するチェックポイントの役目を果たす。もともとは1マイルごとに置かれた里 
程標を示す。 
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7.1 従来型のアウトライン：その功罪 

7.2 アウトラインを構造化するために 

7.3 マニュアルのモジュールを定義する 

7.4 モジュールのさまざまな形：特定のニーズに応えて 

7.5 モジュールにヘッドラインを付ける 

7.6 実証：ヘディングからヘッドラインへ 

7.7 変換：ヘッドラインからアウトラインへ 

7.8 モジュールの数は予想できるか 
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マニュアルへの 構造的 アプローチ 


7.1 従来型のアウトライン：その功罪 


従来型のアウトラインは、複雑な要素をまとめるのに2階層の列挙を行なっている。従来型の 
アウトラインは、各項目の章立てと、それらと階層構造をなすサブ項目群を示している。残念 
ながら、従来型のアウトラインは、作業プランの中で要求されるごくわずかの情報しか与えて 
くれない0たとえば各セクシヨンやマニュアル全体の分量や大きさが指定されているわけでは 
なく、またマニュアルの制作費に関する手がかりを与えてくれるわけでもない。さらにそれは、 
マニュアルの中身を表示する目次としても、読者がどこを読むべきなのかの手助けにはならな 


• 従来型アウトラインの利点 

従来型のアウトラインは、テキストの書かれる筋道や階層構造を表わしたものである。この 
アウトラインを作成するには数字同士、あるいは数字と文字の組合わせを縦に並べ、下層階層 
を表わす（図表7.1)。そして、これに文書の各セクションの中身や趣旨を表わす表題（ヘディ 
ング）を付ける。たいていのヘディングは、名詞と形容詞のみである。 

これら従来型のアウトラインは、技術文書のプランニングにおけるもっとも一般的で便利な 
ツールである。しかし、モジュール化されたマニュアルを開発するためには、それなりの設計 
が必要となるが、従来型のアウトラインでは、そうした設計作業を完全に行なえるだろうか。 
従来型のアウトラインの主な利点は、ライターが自分の考えをまとめるのに役立つという点で 
ある。したがって、1人で仕事をする技術者には理想的なプランニング•ツールである。 

籲従来型アウトラインの欠点 

従来型の アウトラインは、 マニュアルの設計者が、マニュアルの分量 や、 そのマニュアルに 
必要な人員や資材などを見積る上で役立つだろうか。従来型のアウトラインは、さまざまなへ 
ディングの 後に続くテキストを書かなければならない人々に、役に立つ ア ドバイスを与えてく 
れるだろうか。従来型のアウトラインは、 マニュアルの 中身に関する便利な一覧表となり得る 
だろうか。 

ライターが1人で、その書く分量も比較的少なければ、従来型のアウトラインで充分な場合が 
多い。しかし、ライターがチームとして構成され、 マニュアルの 分量が多くて複雑な場合には、 
従来型のアウトラインでは不充分である。それだけでは、 フリーの ライターには、書くべき量 
が分からない。番号が付けられた概略や通常のやり方で書かれたヘディング（動詞的な要素や 
テーマの 含まれて いない もの）だけでは、 マニュアルの 各セクションを どのくらいの 分量にす 
べきか、あるいはどの範囲までをカバーすべきか、などをライターが判断することはできない。 

マニュアル 作成に責任のある マネジャー や アナリス トは、従来型の アウ トラインからほとん 
どデータを読み取ることができない。 マニュアルの 分量、図表の数やタイプなどの情報はもと 
より、もっとも重要な コスト 面での予想はどこからも汲み取れない。 マニュアル 作成において 
は、図や表が コス トの75%〜80%以上を占める場合もあり得るのである。 

•本には階層がない 

結局のところ、この舌足らずな作業プランが、よく分からない内容のマニュアルを産み出し 
ている。しかも読者は、アウトライン中の階層構造がどうなっているかを理解しなければなら 
ないことになっている。ところが、実際にはマニュアルは単一階層であるため、2階層のアウト 
ラインで読者を案内するのは無駄な努力である。 
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4.0 ライブラリアン機能 
4.1 ライブラリアン 
4.2 コア•イメージ•ライブラリ 
4.2.1 プログラムのリストアップと検索 
4.22 段階ーコア•イメージ•ライブラリ 
4.3 ライブラリの再配置 
4.3.1 メンテナンス機能 
4.3.1.1 リロケータブル（再配置可能） 
モジュールのリストアップ 
4.3.1.2 ライブラリ 


管理者の疑問 

分量は7図表の数は7コストは7 


執筆者の疑問 

どのくらい書けばよいか7何を強調すべきか7 
読者の疑問 

どこを読むべきか7読み終わつたのか7 


図表 7.1 く従来型アウトラインの欠陥〉 

この最後の点は、確かに難しいので説明が必要だろう。本が単一階層であるか否かといった 
問題を考える場合には、読者がどう理解するかということではなく、「読者がどのような順番で 
読むか」ということがポイントとなる。ある1つの段落が「論理的」には、他の段落の下層構造 
をなしていたとしても、実際には「書かれている順番」に読まれるのである。 事実上、本には 
階層構造がない。 あるいは文字ではなく一連の画面だとしても、そこには「順番」がある。里 
目2は、実際には項目1の下でも、横でも、後ろでもない。それは項目1の「次」である。 

人間である読者は、順番に読む（並行してではなく）という意味ではコンピュータに似てい 
る。しかし 人間である読者は、円環や回り道や GOTO などの迷路から、何らかの順番を見つけ 
出すことは苦手である。 重要な点は、従来型のアウトラインは、ライター個人の考えをまとめ 
るのには便利だが、便利なマニュアルを企画•設計するツールとしては、不向きであるという 
ことだ。 
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7.2 アウトラインを構造化するために 


マニュアルのみならず、ビデオ•プログラムあるいは一連のヘルプ画面を企画する者は、誰 
でも従来型のアウトラインを作成するところから始めるだろう0それは2段階の階層構造をな 
し、各章には形容詞あるいは名詞句のタイトルが付けられることになるだろう。そこで次のス 
テッブは、このアウトラインを構造化（モジュール化）されたアウトラインに変えることであ 
る0この構造化されたアウトラインでは、各章のヘディングは、ある基準に見合ったサイズと 
レイアウトのモジュール1つ1つに対応し、ヘディングに使われる言葉は、その章で語られる内 
容がよく分かるものになっている0つまり、ヘディングが「ヘッドライン」に昇華するわけで 
ある。 


•構造化アウトラインの2つの条件 

自分の考えを、一定基準のサイズに適合させることのできる人間はほとんどいない。したがっ 
て、作成されるアウトラインは、長さも複雑さも一定していない概念を反映している。アウト 
ライン中の項目 2.1 が、項目 2. 2と同じ長さのセクションであると思い込む根拠はどこにもない。 
また、項目 2. 2が項目 2.2.1 より長いか短いかを知る術もない。 

アウトライン中のへディングも、ほとんど役には立たない。項目 2.1 が「管理上の補助」と呼 
ばれ、 2.1.1 が「サブシステムのアクセス」と称されている、ということが分かったとしても、 
問題の解決にはならない。 

マニュアル作成を構造化された手法で行なうためには、この設計作業に役立つようなアウト 
ラインが必要となるが、これには従来型のアウトラインに欠けている次の2つの要素が必要であ 
る。 


•ライター、校正者、そして最終的には読者に、各セクションに実際には何が書かれて 
いるかを示すような文体。 

•アウトライン中の各記載事項を、ある一定サイズの内容の“切身”に対応させるため 
の基準。 

•へツドラインのさまざまなスタイル 

以上2つの要素のうち、前者は後者に比べると、比較的表面的な問題である。有能なライター 
は、たいてい従来型のへディング（表題）よりもへッドライン*をーアウトラインを作成しない 
場合は、内容一覧（目次）の中で一使用する。何十年も前から、マニュアル•ライターの多く 
は“勘定科目コードの振付け”（名詞3つ)、というような表現を避け、“勘定科目コードを振り 
付ける’’ “勘定科目コードの振付け方” “勘定科目コードの振付けのための6つのルール” “なぜ 
勘定科目コードを振り付けるのか”などの表現を使ってきた。主題を明確に提示するとともに、 
読者の関心を引き出すこれらのヘディング（ヘッドラインといってもよい）は、テクニカルラ 
イティンダが産声を上げて以来、有能なライターの商売道具の1つとなっている。 

•記載事項のサイズを統一せよ 

もう1つの要素ーアウトライン中の各記載事項が、ある一定サイズの項目に対応しているとい 
うこと一は、ほとんどのライターにとって、なじみの薄いことである。事実、多くのアナリス 
卜や テクニカル ライターは、この考えを聞いてびっくりする。量的な変動の激しい概念を、一 
定サイズのユニットにどうしたらまとめられるのか。そんなことが本当に可能なのか、膨大な 
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努力の結果なのかと彼らは思うだろう。 

しっかり把握しなければならないことは、マニュアルに載せるあらゆる情報は、必ず一定基 
準のユニットに統一しなければならない、ということである。もっとはっきりいえば、マニュ 
アルをはじめ、どんな出版物でも一定サイズのページで編纂され、どんなに流動的な“アイデ 
ア”でも、1ページの区画内に収められる。しかしながら、ライターやエディターの多くは、こ 
のパッケージ化のチャンスを見送って いる。 彼らは、1 つの アイデアに何ページくらいが必要か 
をほとんど知らない。彼らは、自分の“申し述べたいこと”がどのくらいの長さになるかを予 
想することができない。実際、彼らはページの切れ目をどこにするかを、タイピストやプリン 
ターやワープロ任せにしている。 

換言すれば、マニュアル設計を構造化する方法においては、読者/ユーザーが目にすること 
になる実際の対象、つまり出来上がったマニュアルのページや画面を設計することが最終目標 
になる0 マニュアルがページごとに編纂されているのに、その作成計画や設計が、なぜページ 

ごとに行なわれないのか。もし各セクション、あるいはユニットを同じサイズにすることが不 

可能に思えるなら、それらの取り得る上限をまず定めて、すべてをなぜそのサイズに統一しな 

いのか。 

もちろん従来型のアウトラインは、マニュアルの各モジュールについての仕様書リストに書 
き換えられるべきである。 

図表 7.2 <従来型のアウトラインと構造化アウトラインの機能の違い> 


従来型の アウトライン 

構造化アウトライン 

•記載事項か 1売み取れず、書いた本人にしか理 
解できない 

• 記載事項が実質的、有益かつ明瞭で、見直しやテ 
ストができる 

• 記載事項がマニュアルの特定の長さやサイズ 
に対応していない 

• それぞれの記載事項が一定の長さの物理的基準に 
対応している 

• 編集作業や最終稿の作成段階にならないと、 
マニュアルの実際の出来ばえが分からない 

. マニュアルの出来上がりの形式やレイアウトは、 
アウトラインにもともと含まれている（モジュー 
ルがすでに定義されている場合） 

• 目的のマニュアルの守備範囲と制作費が、ア 
ウトラインからは伺えない 

•アウトラインがそのまま作業プランになり、そこ 
から制作に必要な経費およびその他の条件が簡単 
に割り出せる 


訳注*ヘッドライン：本書の著者は、ヘディングとヘッドライン、および従来型のアウトラインと構造化され 
たアウトラインを明確に使い分けている。ヘディングとは、構造化されて いない 従来型のアウトライ 
ンの1つ1つの中身に付けられる表題であり、へッドラインとは、構造化されたアウトラインの1つ 
1つのモジユールに 付けられる表題である。 
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7.3 マニュアルのモジュールを定義する 


マニュアルのモジュールは、さまざまな形を取り得る0ただし、各モジュールは、他とはっ 
きり区別できるまで細分化され、単一化されたもので、しかも1つの機能、あるいはテーマに関 
して書かれたものでなければならない0また各モジュールは、「一覧できる」、つまりそのモ 
ジュールの全内容が、ページをめくらなくても見渡せるぐらいの分量でなければならない〇し 
たがって、各モジュールは標準サイズの1ページか、あるいはそれに相当する他のサイズの1ペー 
ジ、せいぜい見開き1ページ （2 ページ分）に収まる程度である。 


•モジュール化とは何か 

モジュール化されたマニュアルとは、技術的な伝達事項を単一目的の、異質な要素のいっさ 
い含まれない状態にまで、小さく区切った切身が集まったものであり、この切身のサイズ、内 
容、体裁があらかじめ定められているものをいう。モジュールの設計一つまり正確な筋道一が 
確定したら、分量が多く、入り組んだ1冊のマニュアルを、小さいほぼ独立したマニュアルの集 
まりとみなすことができるようになる。小型の独立したマニュアルは、それぞれ1〜2時間もあ 
れば書け、順番を問わず、他のマニュアルとは関係なく開発することができる。マニュアル作 
成をモジュール化することによって、各モジュールがばらばらの順番で書かれた場合でも、出 
来上がったときのページと体裁を見積ることもできる。 

參単純な1ページモジュール 

モジュールのもっとも単純な概念は、「1ページ」である。しかし、1ページのリミットは、ほ 
かの刊行物では理想的かもしれないが、マニュアルにおいては、ほとんどの場合やっかいなも 
のである。細かくて乱雑な字体でページを埋めつくすことなく、あらゆる概念（それがどんな 
に単純なものでも）を表現するのには短すぎる。そして、図や表やテキストを同じページに同 
居させるには、“コピーフィッティング*”と、他の印刷技術が要求される。さらに、技術が進 
歩しているとはいえ、図や表の挿入されているページは、ワープロではほとんどブリントアウ 
卜できない。 

籲2ページモジュールの利点 

「2 ページ （見開き1 ページ）」 にまたがる モジュールは、 1 ページよりもメンテナンスが 難し 
いが、応用的な使い方が期待できる。2 ページモジュールの 理想的な構成（すでに述べたように 
20年ほど前 、 Hughes Aircraft Corporation によって開発されたもの）は、図表 7.3 に示したよ 
うなものである。 

A . コントロール•バー：整理番号、ページ、その他の管理データを含んだもの 

B . セクシヨン名 

C . へッドライン（その モジュールのテーマ や機能を盛り込んだ表題） 

D . 要約（あるいは論題）：モジュールの中心概念を展開したもの 

E •テキスト全体（通常500字 < 英文で200ワード >〜2000字く同じく 700ワード〉）：へッドライ 
ンと要約で示された概念を展開したもの 
F •図表：画面、ダイヤグラム、表、図画など一右ページに記載 

見開き1ページのモジュールは、マニュアルを開くたびに一望むと望まざるとにかかわらず一 
人が目にするものである、ということに留意して欲しい。 
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図表 7.3 <大型モジュール〉 

あるモジュールは1ページ、11インチ X 15 インチのコンピュータ用紙1枚に収まることもある。 
あるいは、2ページモジュールの各部分の配列を変えることもあり得る。マニュアル作成者の中 
には、図や表を左ページに持ってくるのを好む者もいる。変化に富んでいる方がよいというこ 
とで、右と左を置き換える者もいる。 

しかし、これらの代替案を表示する前に、次の2つのことを強調しておかねばならない。 

•モジュールの定義は厳格で、不動のものであるが、実際にはかなり柔軟で、モジュー 
ル内の単語や図表の数量に対して、かなりの許容度がある。特に、2ページモジュール 
では、モジュールの実際の“重量（密度）”あるいは容積は、表面上は“同じサイズ” 
でも、様々に変わり得るものである。 

•特に2ページの形式は20年以上前から、官公庁やビジネスの分野の生産技術面の刊行物 
に、さまざまな方法で適用され、成功を収めている。つまりこの形式は、読みやすく 
非常に効果的ということだ。 

この基本的な形式は、必要に応じていくらでも変更できる。たとえば、2ページモジュールで 
は、テキストと揷画の配列を変えることができる。右ページが全部余白になるということさえ 
あり得る0 


原注*コピーフィッティング：最終的な印刷に回す前の原稿をレイアウトする方法。特に図や表を最適の場所 
にレイアウトする作業。 
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7.4 モジュールのさまざまな形:特定のニーズに応えて 


すでに紹介したように、見開き1ページに収められたモジュールは、ほとんどのマニュアルに 
通用する便利なものである。ページをめくらずに内容を一覧でき、1つの機能、あるいは概念を 
盛り込むには充分な大きさである。また、構造化マニュアルを考える上での最小単位を構成す 
るに足る詳細さを兼ね備えている01ページモジュールの例、および個々のニーズに対応する2 
ページ（見開き1ページ）モジュールの例などを以下に紹介する0 


• 1ページモジュールはマニュアルを複雑にする7 

基本的なモジュールは、1ページである。図表 7.4 a は、この1ページの構成案を示すと同時に、 
この1ページモジュールの構造上の欠陥も例証している。つまり、テキストと図表を1ページに 
まとめるという欠陥である。このまとめ方で問題が発生しないならば、図表の形式がよほどよ 
いか、使用した印刷の手法が洗練されているためである。この場合は、1ページモジュールが理 
想的となることもある。 


ヘディング 
要 約 


Type 

ID 

Type 

AN 

Type 

GO 


ヘディング 
要 約 




AT 






XT 

— 




ヘディング 
要 約 


0 —•* 0 



0 


図表 7.4 a <1ページモジュール> 

1ページモジュールが技術的に可能な場合でも、ソフト開発の場合と同じように、モジュール 
が小さければ小さいほど、モジュール間の連結関係は複雑になるということを忘れてはいけな 
い。っまり、それだけ参照、逆戻り、読飛ばし、回り道などの回数が増えるのである。非常に 

小さいモジュールでは、繰り返し書くことができない。したがって、読者を他のモジュールへ 
送り出さなければならなくなる。 

•2 ページモジュールはレイアウトが自由 

2ページモジュールを選んだ場合には、図表 7.4 b のようにモジュール内の構成要素を配置換 
えできる可能性も、同時に選んだことになる。 

モジュールはテキスト半分、図表半分で構成されるという仮定から出発するが、テキストと 
図表の比率を変えた方がよくなる場合も多々ある。モジュールのほとんどがテキストで埋めら 
れるという場合もあるが、このようなモジュールが頻繁に登場するのは、ほめられたことでは 
ない。モジュールのほとんどが図や一覧表などで構成されることもそこそこある。図表を左に 
置き換えたり、折込みサイズにまで広げたりすることもあり得るだろう。 

•その他のモジュール • サイズ 

図表 7.4 c は、変わったサイズのページの使用例を示している。ハーフサイズのページ、ある 
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いはそれ以下のサイズ、11インチ X 15 インチのプリンタ用紙 （24 列 X 120 行）、2フィート X 3 
フイートのポスター、リファレンス.プレースマット、折りたたみ式リファレンス カー ドなど 
がそれである。 


ヘディング 

要約 


x = x+i 
J = J+i 
1 lilB 


ヘディング 


要約 







If a>b 


print a 



Then b=i 


print b 



Else b=r 


print c 







ヘディング 

要約 

— 
















図表 7.4 b 


<2ページモジュール> 


4分 


ページ 


の1 


モジュール 


プリンタ 
一出カモ 
シュール 

irx 】 5” 


図表 7.4 c くその他のモジュール〉 


リファレンス • 
プレースマツト 


[ ポスター] 



f モソユール 


^'x3' 



折りたたみ式リフ 
アレンス カー ド 


モジュールは、表現したい概念の全体を伝えるに小さすぎず、全体的なプランや概要を簡単 
に収めるに大きすぎないものでありさえすれば、考えられる限りのあらゆるサイズ、形態を取 
り得る。 

したがって理想的なモジュールとは、スクロール（画面移動）しないで読める範囲一すなわ 
ち、1画面で構成されるものであろう。この場合、モジュールのリミットとサイズは、開発者の 
持つビデオ•デイスプレイのサイズによって決定されることになろう。 
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7.5 モジュールにヘッドラインを付ける 


各モジュールは、そのサイズや形状にかかわらず、「へッドライン」によって推し進められる0 
ヘッドラインとは、従来のヘディングとは違い、テーマ、概念、主張、さらに論旨まで含めた 
ものである。反対に従来のヘディングは、どんなに詳しく書かれた場合でも、たいてい修飾語 
と名詞だけで構成されるものである0各ヘッドラインは、マニュアルにおける“モジュール1つ 
1つの価値”を決定するものである0つまりそれは、1つのモジュール内に盛り込むことのでき 
るテキスト、および図や表の根幹部分である0 


•へツドラインに盛り込むべきもの 

アウトラインや内容一覧（目次）に使われている従来型のヘディングは、名詞のみ（“ログオ 
ン” “ログオン処理” “電源冗長度”など）、あるいは修飾語と名詞のみ（“相互のログオン処理’’ 
“多重電源冗長度”など）で構成されている。 

これら従来型のヘディングは、セクションの実際の守備範囲や趣旨について、ほとんど手が 
かりを与えてくれない。もちろん、その分量についても、何の目安にもならない。セクション 
の中身を書かなければならないライターや、目次を参照しようとする読者は、アウトラインを 
書いた本人の意図するところを、まったく知る術がない。 

それとは対象的に、ヘッドラインは、論旨、テーマ、強調事項などを表わしている。執筆者 
も読者も、なぜそのセクションが書かれなければならないのか、また何が書かれるべきなのか 
を知ることができる。 

効果的なアウトラインを書くためのキーポイントは、そのモジュールで語られるべきことは 
何なのかを正確に把握することである。注意して欲しいのは、「語りたいことではなく、語られ 
るべきこと」だという点である。よいヘッドラインを書くことは、あなたが1人で書くマニュア 
ルでない限り、他の人があなたをうまく手助けしてくれるための第一歩であるといえよう。 

図表 7.5 a くヘッドラインの種類〉 


スタイル 

例 

動詞的 

• 口座を開く 
•口座の開き方 

• 口座を開く 2 つの方法 

副詞的 

• 署名力ードはどこに提出されるか 
• 口座はいつ開かれるか 
• なぜ XYZ 口座は開設できないのか 

並列的 

• 新規口座：承認するのは誰か 
• 口座番号：どうやってそれを解読するか 
-書式 99 : 身分証明の必要性 

命令的 

• 新しい口座の必要性 
• 加入者リスト更新の電要件 
• 口座振替を確認しない危険性 

平叙文的 

• 1 時間に 10 件の口座が処理されます 
• コード番号を覚えてください 
• 月間報告書は受け取リましたか 
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•中間ステップ：独立アウトライン 

ヘッドラインを書く コッ は、見方を変えれば、マニュアルを一定サイズのモジュールに構造 
化する コッ とは異なる、ということに注意して欲しい。ヘッドラインを書く 場合、 目的のモ 
ジュールの中身の重量や容量と切り離して考えることができるのである。事実、構造化された 
アウトラインを作成するために、“独立アウトライン”という中間的な段階を設けるという方法 
が ある。これはモジュールを考慮せずに、ヘッドラインのスタイルに書き直された ヘディング 
のことである。この方法（後に詳述）では、独立アウトラインが構造化アウトラインへと、さ 
らに練り直されていくのである。 

中身の分かる文体にすることと、モジュールに細分化すること一これら2つの問題を同時に解 
決することは、やっかいなことのように思われる。しかしやってみれば、この方法が意外に簡 
単であることが分かるだろう。モジュールのサイズを知ることは、結局ヘッドラインをより的 
確で、明快なものにすることになる。 

図表 7.5 b は、私個人のマニュアルのライブラリから取ってきた従来型のヘディングの例であ 
る。そして右側を見れば、執筆者が何を意図して、そのヘディングを書いたかが分かるはずで 
ある（余白の部分には、あなたが自分で何か適当なヘッドラインを考えてみて欲しい）。 


図表 7.5 b < ヘディングの書き換え例〉 


変更前 

変更後 

アクセスの仕方 

2つのアクセス形式：シーケンシャルとダイレクト 

ファイル 

システムによるファイル認知：ファイル名と属性 

エグゼクティブ*ライブラリ 

タイムシェアリング.システムは、標準および 
特殊処理ルーチンを供給する 

プログラムのデバッグ 

デバッグ機能の使い方 

FDEBUG の例 

ネームリスト機能 

LOAD/USE コマンド 

透過的書込み* 

例題： FDEBUG でフォートランのプログラムをデバッグする 


原注*透過的書込み： transparent write。 データをファイルに自動的に （ユーザー やオペレーターに意識させ 
ずに）書き込む方法。 
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7.6 実証：へデイングからヘッドラインへ 


この項で示される図表は、従来型のアウトラインが、構造化アウトライン、ヘッドラインの 
リストに変更された場合、どうなるかを表わしている。ヘッドラインの文体は、軽快で会話的 
な（一種の“ショッピング’’スタイル）あるいは直截的で具体的なものにすることをお忘れなく。 


図表 7.6 a では、ほとんどのマニュアルに書かれているシステム導入プランを例に挙げ、新旧 
2つのアウトラインの形式を示している。“旧”バージョンのアウトラインは、データ処理 ( DP ) 
部門の典型的な書式である。しかし“新”バージョンのアウトラインは、ユーザー部門、およ 
びシステム導入によって影響を受ける他の部門に対して、明快に内容を伝えようとする姿勢が、 
かなり明らかになっている。 

図表 7.6 a くシステム導入プランのアウトライン〉 


旧バージョン：従来型アウトライン 

1. 設置環境準備 
1.1 電気系統準備 

1.2 g 然環境準備 

2. 組立て 
2.1 取付け 

2.2 インターフェイス 

3. コミュニケーション 

3.1 コミュニケーション•プロトコル 
3.2 その他のハード構成 

4. テスト 

4.1 コミュニケー ション.テスト 

4.2 メカニカル•テスト 

4.3 ソフトウェアによるテスト 

新バージョン：構造化アウトライン 

1. 必要な電気系統を取り付ける 

2. 適温と清浄さを確保する 

3. カバーとペーパーフィーダーを取り付ける 

4. ケーブルとコネクターを 選択し，取り付ける 

5. プロッターをコンピュータに連結する 

6. コミュニケーションおよびプロトコル•スイッチをセットする 

7. コミュニケーション•チェック•プログラムを作動させる 

8. スタート時の問題を分析する 

9. コミュニケーションの問題を解決する 

10. 機械的な問題を解決する 

11. グラフイックソフト使用の際のスイッチをセットする 

12. 手持ちのソフトでシステムをテストする 
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図表 7.6 b は、一般的なビジネスパッケージ•ソフトのための典型的なユーザー•ガイドのア 
ウトラインである。ただし、訂正後のアウトラインには、2つのバージヨンがあることに注意し 
て欲しい。1つは経理部門の責任者向けで、専門用語、適用範囲、順序などが工夫されている。 
もう1つは経理係向けで、システムのオペレーシヨンを中心に構成されている。 

従来型のアウトラインは、ライターがマニュアルの対象読者とその役割について何か知ろう 
としても、ほとんど役に立たないということに注目していただきたい。 

図表 7,6 b くビジネスパッケージのアウトライン〉 


旧バージョン：従来型アウトライン 

1. 概要 

2. 財務特記事項 
2.1 勘定体系 

2.2 勘定科目の説明 

3. システムの内容 
3.1 支払い管理 
3.2 予算作成 
3.3 予算管理 
3.4 財務報告 

4. 付録：出カサンプル 

新バージョン：構造化アウトライン 
く管理職向け〉 

1. 財務情報システムの活用法 

2. 法律に合うよう勘定科目を定義する 

3. 財務計画、財務分析に利用できるよう 
勘定科目を定義する 

4. 財務報告書の設計 

5. 現在の支出構造の分析 

6. 予算案のシミュレーション 

7. 予算案の実施 


〈実務者向け〉 

1. データ入力 
1.1 売掛金の 人力 
1.2 人 金の入力 
1.3 買掛金の 人力 

1.4 支払い済み金額の人力 
1.5 予算の入力 
1.6 入力の訂正 

2. 報告書作成 

2.1 月間財務報告書の作成 
2.2 四半期財務報告書の作成 
2.3 年度末財務報告書の作成 
2.4 損益計算書の作成 
2.5 予算実績対比報告書の作成 

3. 付録：エラーメ ッ セージへの対応 
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7.7 変換：ヘッドラインからアウトラインへ 


モジュール 化の方法を用いて マニュアル 作成をしようとする者は、いきなりへッドラインを 
構造化するところからは始めない0ヘッドラインの一覧を作成する一般的な方法は、むしろ、 
従来型のアウトラインを作成するところから始まる。次に、それを一連のへッドラインに“分 
解”していく 0その際、各ヘッドラインは、 モジュール 1つ1つの価値を表現するようにする0 


従来型のアウトラインに手を加える場合、たいてい次の2つの変更が同時に行なわれる。 

1. へデイングの表現をヘッドラインのスタイル（文体）とシンタックス（構文）に変える。 

2. その時点で予想し得る最良の“ モジュール”ーモジュールが どのように定義されていたとし 
ても一の記述内容を引き出すようなへッドラインを書く。 

•アウトラインのスタイルを考える 

この2つの作業のうち、前者は比較的簡単である。皮肉なことに、報告書やマニュアルを作成 
する際、従来型のヘディングを書く前に、ヘッドラインを考えてしまう人がほとんどである。 
たとえばライターは、自分の説明したいことが“計算結果の中の誤りを訂正する簡単な方法” 
である、ということを心得ているとしよう。しかしアウトラインは“計算 エラーの もう1 つの 訂 
正手順”となってしまった。また別のライターは“システム B によって、データ転送の遅れを 
解消する 5 つの方法”ということをいいたかったのが、アウトラインでは“システム B :データ 
転送プログラム”としてしまった。つまり場合によっては、へッドラインを書くことは、何が 
書かれるべきだったというもともとのコンセプト作りの段階に一度立ち返って考えることにほ 
かならない。 

•モジュールの中身を見透す 

2つの作業の後者の方は難しい。ほとんどの人、特にプロのテクニカルライターは、画一的な 
区切り方でアウトラインを作成することに慣れていない。彼らは、へッドラインを使うと、い 
いたいことがうまく伝わる、ということを知っているのだろうが一事実、多くの優秀なライター 
は、すでにアウトラインを利用している。ただし、どんなに高度なことをやっているのか、と 
いうことに気付かずに使っているライターもいるが一次のような質問に答えるのは、あまり快 
く思っていない。 

“誤りを訂正する簡単な方法”という内容は、1つのモジュールでまかなえるだろうか？ 特 
にある 1 つのモジュールを“誤りを訂正する簡単な方法一 Part2” と呼ぶことは、技術的につじ 
つまが合わないのではないかという話が持ち上がっているときにはどうか。 

籲独立アウトラインは必要か 

1つの結論として、ある企業やライターは、前述した“独立アウトライン”という中間的な段 
階を設けている。この場合、作ろうとしているマニュアルの再検討を、うまくサポートできる 
ような、明快で、中身の見透せるヘディングであれば、何も同一量の記述内容を引き出すよう 
なものである必要はない。しかし多くの場合、しばらくすると彼らは、この中間的なステップ 
が不必要なものであり、アウトラインに加えられる2つの変更を同時に行なうことは、比較的簡 
単に実現できることに気付く。そして構造化アウトラインは、モジュールの数に関する予想が 
後々はずれることになるとしても、なお独立アウトラインよりも格段におもしろく、また便利 
なものであるということにも気付くのである。 

ここで覚えておいて欲しいのは、マニュアル作成のこの段階においては、各へッドラインが、 
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正確に1つのモジュールに対応している必要はまったくないということである。いずれマニュア 
ル作成者は、モジュールと“1対1に対応する”ヘッドラインの書き方を学ぶ0しかし「読み」 
の正確さについて、あまり神経質になる必要はない。マニュアル作成の次のステップでは、作 
成された各へッドラインが、いくつのモジュールに値するかが明らかになるはずである。 


図表 7.7 <従来型アウトラインの変換> 


従来型アウトライン 構造化アウトライン 


I . 導人 

A . 背景- 1. 販売取引をバッチ処理することの問題点 

B . 開発秘話- 2. コンピュータ処理の3段階の変換 

(取引を3つの処理に分解する） 


II . 操作上の重要項目 
A . —貫性- r 


B . データ処理の基本 



新しいシステムによっていかに操作が簡単になるか 
パ’ッチ処理の廃止 

1つの処理をすることで「すべて」のファイルが更新される 
データ人力はただ一度ですむ 


C . 機密保持_ 
III . 機能 

A . 販売- 

B . 財務—— 

C . 在庫管理- 


7. アクセスは厳しくコントロールされる 

8. 売上げを記録する 

9. 売上げに関連する勘定科目が設定される 

10. 売上げデータはどのように財務ファイルに渡されるか 

11. 売上げデータはどのように在庫管理システムに結び付くか 


図表 7.7 は、従来型のヘディングを、へッドラインに書き直したものの一部である。各ヘッド 
ラインが1つの モジュールに 値しているかどうかは、誰にも分からない。しかしこの時点では、 
誰もはっきり分かる必要はない。 

書き直されたへッドラインの順番は、もとのへディングの順番に対応していることに注目し 
て欲しい。へッドラインは、同じ順番に並んでいるため、ヘディングのサブのような格好になっ 
ている。場合によっては、もとのアウトラインの各部分を置き換える必要がある。設計者がマ 
ニュアルから逆戻りや GOTO をなくそうと思う場合、同時に従来のアウトラインの順番を変 
えなければならないこともある。たとえば、マニュアルを（システム開発の）背景説明から始 
めなければならない理由はあまりない。たいてい、ソフトのもたらす利益や優位点などから始 
めるのか’適当であろう。 
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7.8 モジュールの数は予想できるか 


経験の浅いライターは、初期の段階においてモジュールのサイズを概算したり、モジュール 
として定義されるものが決められた スペース 内にびったり収まる、ということが信じられない 
ようだ0経験豊かなプロのテクニカルライター（彼らはアウトラインをもとにモジュールの長 
さについての見積りを出してはいるのだが）でさえ、モジュールの長さを正確に予想すること 
は避けて通ろうとする0実際には、各モジュールが決められたサイズに収まるかについて、し 
たがってモジュールの個数についての見積りを出せるようになるまでには、1ヶ月とかからな 
い0 


•モジュールのサイズは「上限」にすぎない 

ある1つのアウトラインを見ただけで、そのアウトラインをもとに書くべき項目の1つ1つの 
「正確な長さ」を割り出すことは、明らかに不可能である。しかし幸いなことに、構造化アウト 
ラインを考える段階では、このような見積りは要求されない。 

この段階では、モジュールは、サイズの「上限」（例：1ページ、見開き1ページなど）が定め 
られているだけで、画一的なサイズや長さが定められているわけではない。 すべてのモジュー 
ルを同じ長さにするよりは、長すぎるモジュールをまったく作らない方がはるかに簡単である。 

また各モジュールが見開き1ぺージ （2 ぺージ分）の枠内に収まるものであっても、その長さ 
と内容には著しい違いがある、ということも忘れてはならない。1つのモジュールは、図表のサ 
イズや数によっても違ってくるが、レイアウト*デザインや印刷 • 製本などの調整によって、 
少ないときで200ワード（日本語で約500字）、多いときで1200ワード（同じく 3000字）くらいに 
なるだろう。 

•モジュールの見積りは変更できる 

さらに、構造化アウトラインは、各モジュールのサイズを見積る最後のチャンスではない。 
アウトラインが完成した後に、設計者は各モジュールの簡単なスペックを書くことになるが、 
この時点で1つだと考えていたモジュールが、実は2つ以上であったと考えざるを得ない場合も 
ある。またもっと後でも、スペックが全部モデルやストーリーボードの形で構成されたときに、 
見積りを修正するチャンスがもう一度やって〈る。 

通常、ライターが記述内容をモジュールのサイズにまとめる判断力を養うには、1〜2週間も 
あれば充分である。素人のライターは、ときにプロよりも早くこの技術を身に付けてしまう。 
というのも、古い習慣を捨てるのに数日とかからないからである。ある概念や手順を説明する 
のに必要なサイズに対して物理的な限界を設けるという考えは、最初は過酷な制約のように思 
えるが、すぐに知的な創作活動を促す実用的な規律であることが、おのずと分かってくるだろ 
1 〇 

•余白は多い方がよい 

モジュール 化された マニュアルを 成功させるために、 マニュアル 作成に対する方針を1 つ変え 
なければならない。 モジュールが 小さかった場合に発生する マニュアルの余白を、 進んで導入 
するということである。 マニュアル 作成の責任者の中には、埋められていない白い ページを う 
らめしく思う者がいる。彼らは、費用の無駄使いばかりを気にして、読みやすさやメンテナン 
スのしやすさには、なかなか目を向けない。いわゆる “経済的”な印刷方法と呼ばれるものよ 
り、この読みやすさやメンテナンスのしやすさが、ときには100倍も1000倍も費用の節約になる 

ということが、彼らには分からないのだ。 
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“それではモジュール化されたマニュアルには、余白が多くなりはしないだろうか？”と聞 
かれたら、答えは「たぶんそうなるだろう」である。 













設計 11 :スト ー U ー ボ ー ドと 
モデルを作成する 


8.1 マニュアル作成の問題解決にはモデルが役立つ 
8.2 モジュールごとにモデルを構築する 

8.2.1 どのモジュールにも図表が必要か 
8 . 2.2 1 つのモジュールに多くを詰め込みすぎたら 
日.3動機付けのためのモジュールを設計する 

8.3.1 例：管理職向けの動機付けモジュール 
8.3.2 例：エンジニア向けの動機付けモジュール 
8.4 初心者のためのモジュールを設計する 

8.4.1 例：アナリストのためのチュートリアル•モジュール 
日. 4.2 例：オペレーターのためのチュートリアル • モジュール 
日.5経験者のためのモジュールを設計する 

8.5.1 例：管理者のためのデモンストレーシヨン • モジュール 
8.5.2 例：企画者のためのデモンストレーシヨン • モジュール 
8.6効果的なリファレンス•モジュールを設計する 

8.6.1 例：管理職のためのリファレンス • モジュール 
8.6.2 例：一般社員のためのリファレンス•モジュール 
日.7ストーリーボードをピンナップする 
8.8 ストーリーボードを変更する 
已 .9 redu 门 da 门 cy は排除されるべ$か 
日.10枝分かれと階層構造を操作する 
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8.1 マニュアル作成の問題解決にはモテルが役立つ 


モデルは、お金と労力の節約になる0モデルは、実験的な試みや革新的な試みを、リスクな 
しで実現してくれる。モデルは、誤りを訂正するのに役立ってくれる。その訂正にかかる費用 
は、新しいアイデアや製品を試したり、製品の出荷バージョンを修正するのにかかる費用のほ 
んの一部ですむ0モデルなしでは、マニュアルを充分にテストすることができず、欠陥を訂正 
することさえおぼつかなくなる。 


籲誤りの訂正は後になるほど面倒になる 

図表 8.1 は、作業全般に関するもっとも重要な関数の1つを表わしている。すなわち、誤りを 
訂正するためのコストと、その訂正がなされる時期との関係である。この表は、1つの指数とし 
て見ることができる。つまり、この曲線は、単に上昇しているのではなく、加速度的に上昇率 
を増しているのである。 

プロジェクトが複雑であったり、またプロジェクトで用いるテクノロジーが、これまで使っ 
たことがないようなもので、しかもリスクをともなうようなものになればなるほど、この曲線 
の加速度はさらに増加する。それゆえ、非常に単純で手慣れたプロジェクトには、あまり多く 
の分析と設計は必要ない。ただし、昔からの習慣を再検討することで、もっとも日常的な作業 
が、根本的に改善される場合もある。 

•モデルとは何か 

「モデル」とは、あるものを他のものによって表現することである。モデルは、違う材質で 
(金属製品を粘土で、プラスチックのスイッチを紙で）、あるいは異なるサイズ（ビルの縮小模 
型、原子の拡大模型など）で作られる。この材質とサイズの違いが、モデルを作りやすく、そ 
して何よりも変更しやすくしている。 

労力、コスト 



プロジェクトの進行 


図表 8.1 <訂正にかかるコストの増加率> 
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•マニュアルは1つのモデルである 

モデルは、マニュアルのライターにとって、以下の2点において重要である。まず第一に、マ 
ニュアルとオペレーション•ガイド（操作案内）は、それ自体がモデルになり得るというこ 
とである。もっとも優れた開発グループにおいては、設計チームが“オペレーター•インター 
フェイス（オペレーターがシステムにどう接するか）”に関する仕様を決めたり、それをテスト 
したりする1つの方法として、オペレーション•ガイドを書く。言い換えれば、開発チームは、 
親切なマニュアルを事前に書くことによって、システムが人間と接する部分を定義するわけで 

ある。これが結局、システムあるいはプログラムのその後の設計を導き出す のである。 

(製品開発の初期の時点でマニュアルが書かれることは、極めて例外的なことである。しか 
し、もう気付いている会社が徐々に増えているように、マニュアルはなるべく早い時点で書か 
れるべきである。この方法の数ある利点の中でも特筆すべきは、早い時期にマニュアルを書く 
ことが、とかく後回しにされがちなこと、すなわち「ューザー」がそのシステムで何をしよう 
としているかについて注意を促してくれるという点である。） 

•マニュアルにはモデルが必要である 

第二の点は、マニュアルそのものの開発に関係している。つまり、マニュアルそのもののモ 
デルを作る必要があるということだ。マニュアルが数ページ以上になる場合には、草稿を書く 
前にマニュアルのモデルを作成すべきである。モデルは、各モジュールの内部で何が起こるの 
かを明確にしてくれるとともに、モジュール間の連結、および結合をすべて明示してくれる。 
実際、モデルを作成すれば、各モジュールの技術的な内容が正確かどうか評価でき、モジュー 
ル間の円環や枝分かれの頻度が予測できるはずである。ソフトウェアの開発と同様、マニュア 
ルを読み進む上での筋道が多くなればなるほど、マニュアルの信頼性は下がり、読み間違いも 
多くなる。 

•モデルはマニュアルをテストする 

モデルは、マニュアルをテストするためのものである。そして、テストの目的は、欠陥や間 
違いやバグを見つけ出すことである。モデルを作り、それをテストすることは、われわれの誤 
解を鮮明に浮かび上がらせるものである。また、われわれの意見の相違に焦点をあてるもので 
あり、スケジュールやコストの問題を際立たせるものであり、われわれが欲しているものを手 
に入れることができないということを、あるいはわれわれが欲しているものを必要なときに手 
に入れることができないということを証明するものである。簡単にいえば、モデルは、われわ 
れに誤りを気付かせ、作業のやり直しを促すものである。 

ところが、ライターをはじめ DP や MIS * の関係者の中で、モデルの使用を望む者はほとんど 
いない。私の出会ったクライアントのほとんどが、自分の仕事のどこが悪いのかを知りたがら 
ない。なぜなら、彼らは批評され、試され、検査され、立証され、確認され、評価され、ある 
いは“なおざり”にされることを嫌うからである。 

確かに、批評を好む者はいないということは理解できる。しかし、マニュアルあるいはシス 
テムに長く携わってきた者ほど、批判的な意見を受け入れたがらないのである。だからこそモ 
デルを使って仕事をする場合のもう1つの利点が注目されるのである。つまりモデルは、人が自 
分のプランに惚れ込んでしまう前に、そのプランの欠陥に気付かせることができるのである。 


訳注* MIS : management information system 。 経営情報システム 0 
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8.2 モジュールごとにモテルを構築する 


モジュール•スペックとは、ある1つのモジュールの詳細なプランで、プロジェクトチーム内 
の技術面の専門家、およびコミュニケーシヨンの専門家によって、共同作成されるものである。 
各スペックには、ヘッドライン（アウトラインから書き移されたもの）、モジュールの内容を数 
行でまとめた要約、表や図に関する指示、そして必要ならライターのための若干の注釈、など 
が盛り込まれる。 


•モジュールのスペックを書く 

「構造化アウトライン（ヘッドラインのリスト）」は、目的のマニュアルの設計という点で、 
従来型のアウトラインよりもはるかに明快である。しかし、これはまだ予備的な設計にすぎな 
い。このように、アウトラインだけが準備されている段階では、ヘッドラインに修正する余地 
はないか、案として出されているモジュールは正しい順番に構成されているか、必要な要素は 
盛り込まれているか、あるいは不必要な要素は排除されているか、などを確かめることはでき 
ない。また、各モジュールに盛り込まれるべき要素が、許されたスペース内に収まるかどうか 
を、実際に知ることは不可能である。 


構造化アウトライン 

1 . コンピュータの立ち上げ方 

2. 添付ディスクのコピーの仕方 

2.1 ディスク•ドライブが1台の場合 
2.2 ディスク • ドライブが2台の場合 

3. ファイル名の付け方 





モジュール • スペック 3.0 
* へツ ドライン 
* 要約 

* 図表の説明 
* 注釈(必要に応じて） 


図表 8.2 <モジュール • スペックを書く > 
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マニュアルの真のモデル、つまり、草稿が書かれる前に点検とテストができるような詳細な 
モデルを構築するには、モジュールごとにプランを策定することが必要である。図表8 . 2が示す 
ように、各ヘッドラインにはそれ専用のプランである「モジュール•スペック」が与えられる。 

スペック（仕様書）を書く紙（あるいは書式）は、モジュールのサイズや内容によって異な 
る。しかし、見開き1ページの体裁を取るためのもっとも実用的な（しかも手に入れやすい）用 
紙は、11インチ x 15インチのコンピュータ用紙（印刷済み用紙の裏面も可）である。11インチ x 
15インチシートは、スペックの対象となる11インチ X 17 インチモジュール（通常のコンピュー 
夕.マニュアルの見開き1ページ）よりもほんの少し小さい。 

モジュール.スぺックの作成では、次のような作業がイテなわれる。 

1へッドラインをモジュール.スペックに書き移す0 

2. モジュールの内容を 1 〜 4 行くらいにまとめた要約部分を書く。 

この要約は、完成されたマニュアルの中で、実際に使用されるものである。これは、そ 
れ自体で充分に内容を説明し得る意味がある文章である。したがって“このセクション 
では…”とか“下記の手順で…”など、他の文章に注意を促すような要素は含んでいな 
い。むしろ、モジュール全体の要約版とみなされるべきである。科学論文で使われる専 
門用語でいえば、これは報知的抄録であって、指示的抄録ではない。しかし、この要約 
の中で、モジュール内の図や表に注意を促す場合もある。 

3. 図表を説明する。 

スペックには、プランの検閲者が見て、図表の出来上がりがどうなるか理解できるよう 
に、過不足のない説明が付け加えられなければならない。説明の代わりに、ラフスヶッ 
チ、大まかなグラフや表、あるいは図表の内容を明らかにする2、3のキー•フレーズや 
変数（パラメータ）であってもよい。理想的には、誰もが設計者の望む図表を細部に至 
るまできちんと仕上げることができるように、充分な説明がなされるべきである。 

4. 必要に応じて注釈を付け加える。 

ヘッドライン、要約、図表の説明だけでは分かりにくい場合には、モジュールに何を盛 
り込むべきかについて説明する注釈を付け加えることができる。これも、スペックを 
チェックした者が、完成したモジュールを見て驚かないよう、充分に説明されるべきで 
ある。 


ほとんどの人は、短時間の“トレーニング” （2 〜3時間）で、10分〜15分もあれば、モジュー 
ル.スぺックが書けるようになる。同じようなパターンでモジュールが構成されているマニュ 
アルでは、モジュール•スペックの作成は繰返し作業になるので、モジュール1件あたりの作成 
時間は5分くらいになる。 
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8.2 モジュールごとにモデルを構築する 

8. 2.1 どのモジュールにも図表が必要か 


おそらく、 マニュアル 内のどの モジュール にも、図表が付いていた方が好都合だろう。ここ 
でいう図表とは、ダイヤグラムや画面のハードコピー、絵やイラスト、表（言葉や数字による） 
などである 0 モジュールの 設計がよい場合、図表はあくまで本文の内容を「繰り返して」説明 
するものであり、書かれていないことを補足したり、追加したりするものではない。 


争情報伝達には 「 redundancy 」 が必要である 

どんな モジュールに 対しても、図表が付きものだと考えて欲しい。つまり、各 モジュールご 
とに、最低1つの図表が作成されるよう立案するのである。ただし、どう考えても図表が1つも 
思い浮かばない場合、また、図表を揷入する スペースが 充分にない場合には、 モジュール 1 つに 
対して図表1つ、という考えを捨てる覚1吾を持って欲しい。 

図表に示される内容は、本文の内容と部分的に重複する場合もあれば、完全に重複する場合 
もある。「事実、もっとも完成度の高いモジュールでは、同じ内容の繰返しが行なわれている。 
つまり、ヘッドラインと要約部分がモジュールの内容を表わし、その内容が図表に反映され、 
図表は逆に本文の細かい記述に反映され、それによって質を高められるのである。」しかし、こ 
のような redundancy (繰返し）は、「技術的な情報の伝達は簡潔に」という原則を破るもので 
はないだろうか。 

答えは「ノー」である。確かに redundaucy は、経済効率の原則を破り、短期的コストを上昇 
させるものかもしれない。実際、図表をすべて削除すれば、短期的コストもこれにともない削 
減される。しかし、効果的な意思伝達を間違いなく行なうには、 redundancy が絶対に必要だと 
いうことを忘れてはならない。図表と本文で同じ内容を繰り返すことは、技術情報を伝達する 
もっとも賢明な方法なのである。なぜなら、読者に対して“違う理解”の仕方を提示すること 
になるからである。 

籲図表のさまざまな種類 

大部分の図表はおもに以下のようなカテゴリーに属する。 

• フローチャー トおよび プロセス • ダイ ヤ グラム 

抽象的なシンボルを利用して、事象や物象の具体的な動き、あるいはデータや概念の論理的 
な動きを表わしたもの。また、作業手順を明確にするダイヤグラムもこれに属する。 

• ディスプレイおよび画面の表示 

ビデオ•デイ スプレイあるいはインプット/アウトプット •デバ、 イスにそのとき映し出される 
ものを複写、再生、提示したもの。モジュール1つあたり1つ、あるいはそれ以上の画面を表 
示することは、オンライン•システムを文書化する上でもっともよく用いられる方法となる。 

• ドローイングおよび写真 

現実にある物（場合によっては人物）を描写するために用いられる。 テクニカル. ドローイ 
ングは、対象物（人）を簡単に再現できるため、好んで用いられる方法となっている。一方、 
写真は、対象物（人）の現実感や信憑性を強調したいときに用いられる。 

• “ワード”グラフィック 

おもに言葉で作られた表で、これには簡単な飾り、鄴線枠、矢印などが付けられる。“ワード” 
グラフィックは、マニュアルや技術文献ではまれだが、企画書、報告書、教材などでは特に 
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図表 8.2.1 <マニュアルのための図表> 


ダイヤグラム 

. フロ ー チャ ート 
• ネットワーク図 
• デ—夕 •フロー •ダイヤグラム 
• 階層構造図/ HIPO * 

デイスプレイ 

• 画面 

•ワークシート、フォーム 
.ウインドウ、パネル 

絵 

•イラスト 
• 写真 

• デザイン画（投影図） 

言葉 

• (言葉の）表 

• 擬似コードまたは“構造化言語” 

• “インフオメ ーシヨン.マップ” 

•リスト、プログラム 
•プレイスクリプト 

数値 

• 統計表 

•円グラフ、棒グラフ、折れ線グラフ、面グラフ 
• 方程式、モデル 


有用な方法になり得る（あなたが今読んでいるこのモジュールにも、“ワード”グラフィック 
が含まれている）。 

•プレイスクリプト/ダイヤログ 

オペレーター、ユーザー、 その他の要員を、あたかも1つの ゲームに 対する参加者のように思 
わせる技術である。このプレイスクリプトは、もともと手動のシステムや操作手順のために 
開発された方法で、次の作業に必要なデータを準備するような手順や、相互に影響し合うよ 
うな操作手順を説明する場合などに、非常に都合がよい。 

• 数字および統計に関する表 

数学的表現、グラフ、統計表など、科学およびエンジニアリング全般に関する図表を指す。 

2つ以上のモジュールに対して、まったく同じ図表を用いてもよいだろうか。答えは 「イエス」 
である。多くのテクニカル •エディター およびマニュアル作成マネジャーは、この答えに難色 
を示すであろうが、私が強調したいのは、参照すべき図表が見あたらないという重大なミスを 
犯すよりも、同じ図表を繰り返し用いる方がましであるということだ。 

一方、多くのマニュアル作成者が経験的に気付いていることだが、“同じ”図表を数ヶ所で引 
用したとしても、事実上参照されるのは、画面上の異なるフィールドだったり、表の異なる箇 
所だったりする。確かに、現在一般的に用いられている方法では、一度図表を作成したら、そ 
れをテキストのさまざまな場所から参照することになる。しかしもっとスマートなやり方をす 
るなら、各参照事項ごとに別個の図表を作成するのがよい。さもなくば、“同じ”図表を使うと 
しても、その場で參照すべき部分を強調するか、浮き立たせるようにするのがよいだろう。 


訳注* HIPO : Hierarchy plus Input - Process - Output 。 ハイポ。データ•フロー•ダイヤグラムでは、処理の流 
れは分かるが、各モジュールの階層構造がつかめない。逆に階層構造図では処理手順がはっきりしな 
い。これら2つの図の欠点を補い、利点をうまく兼ね備えたのが HIP 0 である。 
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マニュアルへの 構造的 アプローチ 


8.2 モジュールごとにモテルを構築する 

8. 2. 21つのモジュールに多くを詰め込みすぎたら 


図表の大きさや位置を調整したり、活字のタイプやページの書式を変えることで、たいてい 
の場合、きつちり収まつているモジュールに、もう少し情報を“割り込ませる”ことが可能で 
ある0—般的には、ある概念や処理手順が1つのモジュールに収まり切らない場合は、最低3つ 
のモジュールに分ける必要がある。 


•モジュールは画ーサイズではない 

マニュアル作成者が、標準サイズのモジュールで執筆しようとする際、まず最初に問題とな 
ることは、1ページないし2ページの制限内に収めるには大きすぎるモジュールをどうするかと 
いうことである。 

しかし、 モジュールの標準サイズは「上限」であって、画ーサイズではな いということを思 
い出して欲しい。設計者およびライターがモジュールを考える場合、実際には書くべき内容の 
ひと区切りがモジュール1つ分のサイズで「まかなえる」かどうかを考えているのであって、画 
ーサイズの記述を考えているのではない。結果として、ほとんどのモジュールにはホワイトス 
ペース（余白）ができる。その余白はもっぱら、各モジュールを読みやすくするのに役立つだ 
ろぅ。 

しかしながら、目 いっぱいに 書き込まれた モジュールについては、 改善すべき点が山ほどあ 
る。図表、グラフ、イラスト、揷絵などのアートワークを小さくするか、テキストを若干縮小 
したり、切り詰めたりすることもできる。ただし、ほとんどの出版関係者は、 ページによって 
活字の大きさを変えるのを好まない。 

他にも、雑然となったり読みにく くなったりすることなく、モジュールの容量を広げる方法 
はたくさんある。たとえば、「横に個条書き」にされたようなテキストでは、イ亍数を増やさずに 
10〜20%程度は記述を追加することができる。「均ースペース印刷」にも同じような効果が期待 
できる。しかし、気を付けなければいけないのは、（アメリカにおける）現在の代表的なオフィ 
ス用ワープロは、均ースペーシングを採用して「おらず」、単語間に余分のスペースを取ること 
で右マージンを調整している、ということだ。こういう場合は、単純に右揃えをやめて、“右側 
が不ぞ ろいのま ま’’の印刷法を採用することで、たいていのワープロでは、1ページあたりの容 
量を増やすことができるだろう。 

詰め込みすぎのモジュールから、内容をいくらか「削る」という方法もある。ただし、削除 
しても、モジュールの分かりやすさと有効性が失われないことがはっきりしていればの話であ 
る。 

籲大きすぎるモジュールは最低3つに分けられる 

ある処理手順や概念が、マニュアルの1つのモジュールに収めるには大きすぎるという事実 
は、テストケースとして極めて重要なものである。つまりほとんどの場合、その処理手順や概 
念を 1 つのまとまりとして見るには大きすぎるということである。特に、モジュールが 8. 5 イン 
チ XII インチのページ 2 ページ分という大きなものである場合、そのモジュールに収まらないも 
のは、おそらく1つのものではなく、いくつかの小さなまとまりが集まったものとみなした方が 

よぃ0 

図表 8.2. 2が示すように、大きな概念を単に2つの段階（フェーズ）に分けても、あまり筋の 
通った分かりやすいものにはならない。むしろ、まず全体の概論あるいは1つ上のレベルとして、 
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階層なし(望ましくない) 


第2階層まである 


第3階層まである 


(注） 、、 FM " は '' Fat Module (詰め込みすぎモジュール)〃の略 

図表 8.2.2 < “詰め込みすぎモジュール”を分解する> 

「その処理手順には2つの段階がある」ということを説明し、次にその2つの段階に1つずつモ 
ジュールをあてはめていく方がより分かりやすく、筋が通りやすい。したがって、2つの段階に 
分かれる処理手順には、3つのモジュール（第一階層1つと第二階層2つ）が必要であり、3つに 
分かれるものには、4つのモジュールが必要、という具合いになる。 

アウトラインの作り方によっては、各ヘッドラインの守備範囲が広すぎて、最初は1つのモ 
ジュールに入ると思っていたものを、3段階の階層に分けなければならない場合も出てくる（上 
図参照）。 

確かに、操作手順を1つのモジュールで表わせれば、階層構造や枝分かれを必要とする場合よ 
りも理解しやすく、簡単に実行することができる。そこで、 特に詰め込みすぎのモジュールを 
見つけた場合、マニュアル作成者にとってもっとも賢いやり方は、手順それ自体を変えるよう 

開発者を説得する ことである。この方法は、マニュアルの書き方を簡単にするだけではなく、 
使用されるコンピュータ技術そのものを、もっと使いやすく信頼性のあるものにすることにも 
なる。 
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マニュアルへの構造的アプローチ 


8.3 動機付けのためのモジュールを設計する 


動機付けのモジュールとは、読者のあまりやりたがらない事柄をあえてやらせることを目的 
として作成されるモジュールである0そのモジュール内に書かれている手順や方法を踏むこと 
によって、何らかの「利益」を得、それをやっておけば、やらなかった場合よりも、確実に多 
くを得ることができるのだ、ということを読者に納得させる必要がある。 


マニュアル作成者が、いかに自分を“技術者”とみなしているとしても、自分の考えや方法 
を読者に売り込むことを怠ってはならない。オペレーター.マニュアルとユーザー .マニェア 
ルには、動機付けのための要素がいくつか含まれているのが普通である。すなわち、システム 
の「特徴」を、読者の「利益」として提示するモジュールである。 

•システムの特性を分類する 

どんなシステムも、他の違うシステムに取り換えられる。取り換えられる前のシステムと後 
のシステムの違いとして、次のような特徴を挙げることができる。ほとんどの特性が以下のそ 
れほど多くないカテゴリーにあてはまる。 

•物理的側面一構成要素、サイズ、重さ、温度、設置位置、数量、一般的外観、音など 
•操作的側面ースピード、周期、ステップ数、“能力”（できることとできないこと）、他の 
ものとの互換性など 

•利用しやすさ一在庫数、習得時間、納品までの日数、サービス期間、取得原価、運転費用 
など 

•完成度一簡潔さ、厳密さ、正確さ、精密さ、信頼性、多機能性、拡張性など 


•システムの特性はユーザーの利益 

繰り返していうが、システムの交換を行なおうと思うなら、読者に推薦するシステムや手順 
は、上記の特徴付けのどれかに照らして、取り換えられる前のものと、明らかに異なっていな 
ければならない。そこで問題は、これらの特徴の1つ1つを、さまざまな利益の上に位置付けて 
いくことである。 

一番犯しやすいミスは、「ユーザーの能力に関する落とし穴」である。すなわち、多くのライ 
ターが、システムにもともと備わっている以上の特性をどんどん積極的に見つけ出してくれる 
人々がたくさんいる、と考えていることである。しかしながら、そういう人々は、エンジニア 
やアナリストが考えているほど多くはない。 

•どんな利益に訴えるか 

もっとも一般的な動機付けは、もちろん「物質的な利益」に訴えることである。書かれてい 
る通りにやれば、ユーザーは「お金を儲けるか、節約する」ことができるはずである。一番宣 
伝しにくいのは、やはり、短期的な高額出費が、その出費を上回る長期的な節約につながる、 
ということを人々に納得させることである。 

物質的利益の他に考えられるのは、「心理的利益」である。すなわち、敬意、地位、名声、知 
名度、信望、気晴らし、快適さ、影響力、自主性などである。動機付けを専門とする人々によ 
ると、これらの心理的利益は、少ない物質的利益よりも一特に準社員（正社員以下）を相手に 
するときは一重要であるという。たとえば“影響力”は、自分の部署をもっと思い通りにあや 
つりたいと思っている管理職にとって魅力的である。しかし、同時にそれは、もっと思い通り 
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図表 8.3 <動機付けのためのモジュールを設計する> 

に“自由時間”をあやつりたいと思っている事務員にとっても魅力的である。 

「道徳心や知性にアピールする」やり方は、、アメリカのビジネス界や政界ではあまり使われ 
ない。このアピールとは、正しいから、公平だから、啓発的だから、あるいは気高いから何か 
をするということである。ある特定の団体（大学や宗教団体など）において、またある文化全 
体においても、こうしたアピールは、われわれの社会の人間が、損益計算書の最終行に何とか 
もっとよい結果を書き込みたいとがんばるように、人々を新しい試みへと駆り立てるものであ 
る。 

強調すべき点は、これらの利益は、システムの特性の中では、何ら具体的には示されないと 
いうことである。新しいシステムの「コスト面での特性」でさえ、必ずそれが読者に物質的利 
益をもたらしてくれるという、充分な説明と理由付けが必要になるだろう。 

マニュアル作成者は、読者/ユーザーが何を欲しているかを分析し、指示された作業を行な 
えば、必ず欲しいものが手に入るのだということをーモジュールの要約部分に一明示しなけれ 
ばならない。そして図表は、たいていの場合、その作業を行なったときと行なわないときを並 
ベて、どちらが得かを比較するものでなければならない。 
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マニュアルへの 構造的 アプローチ 


8.3 動機付けのためのモジュールを設計する 

8.3.1 例：管理職向けの動機付けモジュール 


下の例は、ある大手国際銀行のシステム•プランからの抜粋である（私が書いたものではな 
い）。この簡単な表を見れば、導入を勧められている製品が、どれだけ経費を節約してくれるか、 
労力を削減してくれるか、そしていかに既存の技術を駆使して作られているか、ということが 
分かる。要約部分で、この動機付け要因をもっと明確に説明していたら、もっとよくなつてい 
ただろう。 


3 . CRX 対代替案 

CRX Loan System の採用に対して、次の3つの代替案が挙げられている。 
• 現行の商業ローン （ C / L ) システムの開発を続行する。 

• 新しい C / L システムを検討する。 

• いずれかの業務機能を断念する。 

代替案はすべて手間を取りすぎるか、コストがかかりすぎる。 


CRX Loan System は、当銀行の各部署で現在使用しているシステムと同種か、または互 
換性を持つものである。そのプログラミング言語、レコードのレイアウト、インプット/アウ 
トプットのフォーマットは、すでに他の部署でおなじみなので、 CRX を現行のローン手続きと 
合併させるのは簡単で能率的でもある。下記に示した CRX 導入の利点に注目して欲しい。 

• 当銀行のシステム•アナリストは、すでにこの製品を知っている。 

• この製品は多くのユーザーによってテスト済みである。 

•出力書式、操作手順、マニュアルはすでに出来上がっている。 

•ソフトには、すでに開発料が支払われている。 

代替案 


現行の C / L システムの開発を続行すると... 現行の バージョン 2. 4を大幅に変えな く てはな 
らない。すべての表示画面に新しい フィー ルドを加え、 マスター ファイルを拡張しなくてはな 
らない。この変更は大変手間とコストがかかるため、新型 ローン システムは、完成する前に時 
代遅れになってしまう。 

他の C / L システムを検討すると….検 討に時間がかかる。新システムを購入しなくてはなら 
ない（一方われわれはすでに CRX を所有している）、そしてさらに学習や指導に時間がかかる。 
[また、準備費用の査定を見ても、 CRX が他より勝っている。] 

いずれかの機能を断念すると... 高利回りの企業貸付を、あまり大量に記帳するわけにはいか 
なくなる。一方細かい非能率的な貸付業務を処理する必要性は、これからますます増えていく 
はずである。 
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CRX 

代替案 

* 安価 

* 高価 

* 速やかな開発が可能 

* 開発に時間がかかる 

* テストおよび実証済み 

* 無からのスタート 

* システムの専門技術はすでにおなじみ 

* ??? 


図表 8.3.1 < CRX 対代替案〉 
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マニュアルへの構造的アプローチ 


8.3 動機付けのためのモジュールを設計する 

8.3. 2例：エンジニア向けの動機付けモジュール 


下の例は、ある軍事施設に勤めるエンジニア向けの ユーザー ガイドから抜粋したものである 
(私が書いたものではない）。動機付け要因は、要約の部分にはっきりと示されている。つまり、 
技術の説明はもとより、「選択権」一すなわちエンジニアが自由に仕事のやり方を選べること一 
が示されている。右ページの図表では、機能の差は比較されているが、選択権に関する動機付 
けについては強調されていない。 


1.3 ランダム.アクセス.カーブ.ファイル*はエンジニアにとって都合がよい 


これまでわれわれは、どちらかというと柔軟性を欠くカーブ.ファイルの設計から離れられ 
ないでいた。現在、ランダム.カーブ.ファイルのおかげで、自動ユニット変換、有意曲線名 
や有意パラメータ名、そして、より多彩なサポート•ソフトウェアなどを持つことができる。 
曲線は、現在最大8個の独立パラメータと50個の従属パラメータを持っている。 


かつては曲線は、比較的意味のない“曲線番号”によって認識されていて、その中のデータ 
は、曲線の X ， Y ， Z ， または W 変数と呼ばれていた。気の毒なのは、自分の仲間が度による 
ALFA で CLALFA 曲線を作り、自分のプログラムでは、 ALFA はラジアンを返すと想定して 
いた技術者である。あなたが“ Z ” でなく “ W ” 変数の線をプロットしたいといったとき、なぜ 
プログラマーが頭にきたか？ また、あなたの UFTAS プリンター出力が、大量の外揷メッ 
セージ内で失われた回数はどうだったか？ 

現在では曲線は名前で認識される。（そのため、曲線番号の レンジに 関して起こりがちな誤り 
はもうな い）。 曲線を作って いる 変数は、 ユニッ トと同様に、名前を持つ。今では、自分のデー 
夕をどの ユニットに 入力した いかをソフトウェアに 指示することができ、残りの処理は、新型 
の自動 ユニット 変数機能がやってくれる。 

プロット •パッケージが あると、どの変数を X 軸として選んでもよいし、その他のどの変数 
を“〜の線”としてプロットしても構わない。自分のデータをどの ユニット 内にプロットする 
かを選ぶことができ、プロット上で自分の変数をどう呼ぶかさえ選ぶことができる。 

曲線は、以前よりはるかに大きくすることができる。最高8個までの異なる独立変数の関数で 
ある曲線を操作できるようになった。曲線は、多くの従属パラメータ（実際にはそれぞれ50個 
まで）を持つことができるようになった。 

プロット•パッケージに加えて、サポート•ソフトウェアは、 UFTAS 曲線の作成、検査、 
組合わせ、印刷、再フォーマットの各機能、およびテクトロニクス•デジタイゼーション•プ 
ログラムを内蔵し、それらによって完全でパワフルなパッケージが形成されている。 
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新しいランダム • 

アクセス • 力_フ • 

ファイルの利点 

機能 

古しヽカーフ- 
ファイル 

新しいランダム • 

力ーフ • ファイル 

1 . 

力ーブの参照方法 

数値 

有意名 

2. 

パラメータの 参照方法 

X ， Y ， Z，W 変数 

有意名 

3. 

パラメータユニット 

なし 

あり 

4. 

自動 ユニット 変換 

なし 

あり 

5. 

プロットの柔軟性 

皆 M 

はるかに柔軟で多彩 

6. 

独立 パラメータの 数 

最大3コ 

最大8コ 

7. 

従属パラメータの数 

1 コのみ 

最大50コ 

8. 

アーギユメント呼出しのた 
めの検索ルーチン 

標準 

より柔軟な有意名 

9. 

サポート•ソフトウエア 

CREATE 

CREATE 



PLOT 

PLOT 



PRINT 

PRINT 

AUDIT 

MERGE 

CONVERSION 

DIGITIZING 

10. 

外挿 

必須 

ON / OFF の切換え可能 

11. 

効率 

悪い 

よぃ 


図表 8.3.2 


原注*ランダム•アクセス.カーブ.ファイル ： random access curve file 。 CAD (コンピュータ援用設計） 
で製図を行なう場合に使用される曲線の形状を定義する特別な方法。 
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8.4 初心者のためのモジュールを設計する 


初心者のためのチュートリアル（指導用）モジュールでは、ある1つの概念あるいは作業が提 
示される。その概念あるいは作業は、すでに読者が習得していることであるかどうかが確認さ 
れなければならない0マニュアル作成者は、そのモジュールの意図するところを、読者がそこ 
でマスターすべきある特定の項目の観点から定義し、読者はそれを確実に会得することを要求 
される。その際の方法としては、質問に答えていく、簡単な操作を実行していく、あるいはチュー 
トリアル（プログラミングされた教科書の一種)の指示に沿って進んでいく、などがある。 


籲読者に問いかけ、実際にやらせてみる 

初心者のためのチュートリアル.モジュールには、新しいことが何か1つ含まれている。 

ライターが、効果的なチュートリアル.モジュールを設計できるようになるには、 そのモ 
ジュールから読者に何を学び取らせたいのか を、まず明確にすることができなければならない。 
そして、この目的をうまく達成しようと思うなら、学び取らせたい概念や考え方に焦点をあて 
た作業やテストを考えるのが一番便利な方法だろう。読者がある質問に答えられ、ある選択を 
行なうことができ、ある作業工程を完了させることができ、学ぶべきものを マスター したと確 
信できたとしたら、そのモジュールは成功したといえるだろう。もっと高度な教育的記述内容 
においては、ある作業にどれくらい時間をかけられるか、あるいは答えの中に間違いが いくつ 
まで許されるかなど、いろいろな限定条件が設定される場合もある。 

籲初心者のためのモジュール 

図表 8.4 a に見る例は、経験のあるオペレーターにとっては、わざわざ質問されるようなこと 
ではないかもしれない。しかし、初心者を対象とするときは、これがまさに正しい伝え方なの 
である。（注：チュートリアル•モジュールは、ごく小さい スペースで 足りることが多い。1ペー 
ジのモジュールだったり、従来の 8. 5インチ XII インチよりも小さいページですんでしまうこと 
もまれではない。） 

•オペレーターのためのモジュール 

図表 8.4 b の例は、オペレーターに関するもっと典型的な記述である。通常、 この作業は“解 
答画面’’を作成することであるため、マニュアルは実際の端末操作と並行して使われなくては 
ならない。（実際にシステムを運用している読者を想定しない限り、一連のチュートリアル•モ 
ジュールをどのように提示すベきかを想像することは難しい。特に経験のない読者を相手にす 
る場合、実際に行なわせてみなければ、基本的な作業を習得させることは不可能に近い。） 


< L > を押すと、ログ • ディスク • ドライブが 
変更されます。 

“ L ” は何の略でしよう7 


図表 8.4 a 
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コピー • プロテクトがかかる 
立ち上げ可能になる 

s タイプのコンピュータならどれでも使えるようになる 
自動的にパックアップが取られる 


図表 8.4 b 


力ーソル•キーとインサート•キーを使って、 
画面1を画面2に変えてください。 



画面1 



画面2 


FORMAT / S コマンドでデイスケツトを初期化するとします。 
この場合、デイスケツトにセープされるプログラムは—— 


図表 8.4 c 

•初心者に効果的なチュートリアル 

図表 8.4 c のような選択肢による簡単な質問形式が、本の中（プログラムに組み込まれた教科 
書である場合もある）やコンピュータによる一連の操作説明用画面の一部として現われること 
もある。教科書をプログラムに組み込むことは、初心者を教育するのにもっとも効果的な方法 
ではあるが、おもしろいことにプロダラミングされたテキスト（一般にチュートリアルという） 
は、設計がよければよいほど、読者にスキップ、ジャンプ、ブランチ、回り道などを強いるこ 
ととなる！問題は経験のない、あるいは目の離せない読者である。つまり、このような読者 
が、プロダラミングされたテキストの中で道に迷った場合、後戻りできないということである。 
この問題の解決策としては、「オンライン •チュートリアル」 がある。これもプログラミングさ 
れたテキストの一種だが、読者は枝分かれの状態を“意識しなくてもよい”ようになっている。 

もっと込み入った記述内容の場合には、明らかにスペシャリスト、つまり教育技術の専門家 
の技能が要求される。 


12 3 4 
F F F F 
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マニュアルへの 構造的 アプローチ 


日. 4初心者のためのモジュールを設計する 

8.4. 1例：アナリストのためのチュートリアル•モジ = l ール 


下の例は、ある指導用マニュアルから抜粋したもので、それはあるコンサルティング会社の 
財務アナリストに、統計表を作り、処理する新しいプログラムを紹介する目的で作られた（私 
が書いたものではない）。この場合読者は、こうした特殊なシステムについては初心者である 
(データ処理一般についてではない）。このモジュールには、要約の部分がない0したがつて、 
簡単な質問を1つか2つ付けて、読者が変数領域をストアする3つの方法の違いを理解し得たかど 
うか確認するとよい。 


18. 変数定義コマンドをストアする3つの方法 


変数定義コマンドをストアする次の3つの方法のうち1つを選んでください。 

テーブル.メンバー . これは 区分け されたテーブル • ファイルの一部として、ストア 

された変数定義コマンドの1セットです。1つのテーブル•メン 
バーにストアできるコマンドは、 DEFINE , IDENTIFY LIST , 
ADD TRANSFORMATION の 3 つです。 


バイナリ.テーブル . これは上記のテーブル.メンバーと同じ変数定義コマンドの1 

セットです。ただし、2進法による圧縮されたフォーマットで 
コード化されていますので、スピーディーで効率のよい登録お 
よび呼出しが可能です。このバイナリ•テーブルにストアでき 
るコマンドは、 DEFINE , IDENTIFY LIST , ADD TRANS - 
FORMATION の 3 つです。バイナリ•テーブルは、変更あるい 
は締集することはできません。 

コマンド.データ.セット…これも変数定義コマンドの1セットですが、カード形式で登録さ 

れます。ただし、 テーブル•ファイルの 一部としては、 登録で 
きません。この コマンド.データ •セットには、 あらゆる テ ー 
ブル.コマンドを ストアすることができます。 コマンド.デー 
夕•セットは、編集したり変更したりすること ができます 。 

テーブル•メ ン バーや コマンド.データ •セットを作るには、 UNI - COLL の QED あるいは 
IBM の EDIT などのテキスト編集プログラムを使います。テーブル•メンバーを登録するため 
のテーブル•ファイルを作るには 、 BUILD TABLE FILE を用います。バイナリ•テーブルを 
作るには 、 WRITE BINARY TABLE を使用します。 


テーブル•メンバーを呼び出すには READ TABLE を用いますが、その前に目的のメンバー 
をストアしてあるテーブル•ファイルを 、 SELECT Table File で選びます。バイナリ•テー 
ブルを呼び出すには 、 READ BINARY TABLE を用います。 
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〈変数定義コマンドをストアする3つの方法〉 


DEFINE 
DEFINE 
DEFINE 
IDENTIFY LIST 
IDENTIEY OBSERVATION 
IDENTIFY OBSERVATION 
ADD TRANSFORMATION 
ADD TRANSFORMATION 
ADD TRANSFORMATION 
IDENTIFY LIST 
IDENTIFY LIST 


\.E 



TABLE 

Ml 


TABLE 

VI 


TABLE 

IX 


テーブル • メンバーは区分け 
されたテーブル • ファイルの 
一部。これにストアできるコ 

マンドは DEFINEDENTFY、 
ADD TRANSFORMATION 


テーブルファイル 
(区分けされた データの 1 セツト ) 


バイナリ • テーブルは2進法によ 
る圧縮されたフアイルとしてスト 
アされたテーブル • メンバーの一 
種。登録と呼出しがより素早く効 
率よくできる。 



DEFINE、1DENTIFY 




丁 ABLE 

1 


AND ADD 

TRANSFORMATION 

TABLE 

IV 

TABLE 

VII 

COMMANDS、ENCODED 

IN A 巳 INARY 

FORMAT 




SELECT DATA PERIODJ970J973 
SELECT FUNCTION LAG MULTIPLE 闩 、 4 
SELECT 巳 ANK 、 BANK='WEFATS 、 WEFA.QTR 
SELECT LAG CONVERSION'YES 
SELECT TABLE FI し E 、 MYTA 巳 S 
READ TAB し E 、 TA 巳 8 
EXECUTE TABLE 

CLOSE 巳 ANK 、 'V\/EFATS.\A/EFA.QT 闩 ’ 


バイナリ • テーブル 


コマンド • データ • セツトは 
どの TABLE コマンドでもス 
トアできる。これはカード形 
式でストアされ、テーブル* 
ファイルの中にはストアされ 
ない。 


コマンド • データ • セツト 


図表 8.4.1 
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8.4 初心者のためのモジュールを設計する 

8.4. 2例:オペレーターのためのチュ ー トリアル•モジ^ール 


下の例は、軍事基地に電話回線をひく手順を指導するために作られたマニュアルからの抜粋 
である（私が書いたものではない ）0 これは、オペレーターに新しい技術 （ LOAD コマンドの使 
用法）を教えている0このモジュールは、簡単な質問を付け加えることによつて改善できるだ 
ろう。 


モジュール11.0 ユーザー/オペレーターマニュアル 84年1月 


Post ” から “ Base ” にデータを動かすためにく L 0 AD > オプションを用いる。 


《 LOAD 》 オプションは、《端末処理》からでも《条件設定処理》からでも使用することがで 
きる。 《 LOAD 》 を呼び出すと、システムは補助データベース “ POST ” からデータを読み、 
必要な条件、端末、データベース “ BASE ” の中に構築すべきものを定義する。 


モジュール10、および 10 A に説明されている操作をした後、システムの《ファイル処理》の 
部分にある、 《 LOAD 》 オプションを呼び出せばよい0このオプションが呼び出されるたびに、 
システムは “ POST ” という補助データベース内のデータを読み、補助データを “ BASE ” とい 
うメイン • データベースに転送するために必要なあらゆる調整を行なう。 
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図表 8.4.2 



端末処理 


条件設定処理 


条件設定処理 
の load J 


端末処理_ 

load 




原注* BACEDS :合衆国陸軍の軍事基地で使用される電話ネットワークを形成するシステム。 
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8.5 経験者のためのモジュールを設計する 

初心者に必要な情報の1項目を指示するチュートリアル • モジュールと違って、「デモンスト 
レーシヨン（実演）のためのモジュール」は、1つの機能、作業、活動などの全体を示すもので 
ある。これは簡潔かつ明快、そして何よりも正確でなければならない。 


癱デ モンストレーシヨン•モジュールは1つの処理を説明する 

デモンストレーション•モジュールは、明快に書かれ、きちんと整理されていれば、実質的 
な情報のひとかたまり、つまり完全な手順や処理、プログラム全体やプログラムの各モジュー 
ルを表わすことができる。 

このようなモジュールの読者は、記述の正確さを求める。つまり、モジュールに書かれた手 
順通りに行なえば、いつも正しい結果が得られなければならない。もしそうでなければ、読者 
はマニュアルのライターとシステムの開発者に文句をいうだろう（これと反対に、初心者だつ 
たら自分自身を責める傾向にある）。 



正確さを確かめる 


レベルは 7 

複数 /単独 


階層または 
段階 ( フヱーズ） 
に分解する 


明可能 7/ 
YESXVNO 


モジュール 

スペックを 

書く 


チュートリアル•モジュール 
を書く 


手順を修正する 


スペックを書く 


図表 8.5 < デモンストレー シヨン. モジュールを設計する〉 
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図表 8. 5が示すように、 ある 1 つの デモンストレーション•モジュール、あるいはそれらが 複 
数集まって階層構造をなしたものを企画する場合、まず最初に、 対象読者が経験豊かな自信に 
満ちた者で あり、チュートリアル.モジュールの 設計のような特別な配慮は、 いっさい 必要な 

い者であることを確認しなければならない。 

次は、モジュールの設計者の仕事で、説明しようとしているプロセスー通常、人がどのよう 
に作業を行なうと推測されるか一の要約を書くことである。この要約は、説明内容や条件付き 
の処理などの単純明快なリストでなければならない。 

驚いたことに、 マニュアル や オペレーション. ガイドのライターたちの多くは、説明しよう 
とする事柄の実際の正確なやり方を知らないままに書き始めてしまうことが 多い。マニュアル 
作成者は、これらの要約をただ書けばよいと いう ものではなく、それらをテストしてみる必要 
がある。 

すでに存在している手順を書き上げる場合、テストは簡単である。つまり、われわれは、プ 
ログラムあるいはデバ'イスが期待通りに動くかどうかを見るため、記述の指示通りに（「余計」 
なことはせずに）やってみてくれる人を探せばよい。システムがまだ開発中の場合は、プロセ 
スの要約は、検閲者によって正確かどうかがテストされなければならない。実地テストで1回だ 
けうまくいったとしても、さまざまな条件下で最高の状態が保証されなければ意味がない。 

もちろん、ある特別の場合は、この手順がごく初期のプランあるいはスペックの一部である 
こともある。この場合は、手順を確認するよりも、開発者がスぺック通りに働くシステムを作っ 
ているかどうか確認する方が大切である。 

•手順が1つのモジュールに収まらなかったら 

マニュアル設計時のもっとも興味深い問題は、プロセスあるいは処理が、「1つのレベル」か、 
あるいは「複数のレベル」の手順かを決めることである。簡単にいえば、モジュール1つに収ま 
るかどうかを決めることである。 

もし「1 つのレベル」 なら、つまり手順に関して言及されるべき すべてのことが 1 ページ ある 
いは 2 ページのモジュールで 扱える場合には、設計者は要約を書き、手順を簡単に図式化したも 
のを スケッチして、 モジュールの スペックを作成する。 

しかし、その処理全体が、複数のモジュールを必要とした場合はどうか。 

ある1つのプロセスが、1つのデモンストレーション.モジュールには大きすぎるものだった 
ら、それらを階層構造に分ける必要があるだろう。つまり、上部構造のモジュールが1つ必要で 
ある。このモジュールは、説明すべきプロセスの1つ1つの構成要素にあてられた複数のモジュー 
ルを下部構造として持つことになる（第ニレベルまである階層構造となる）。第三ないし第四レ 
ベルまでの階層構造になることもある。 

プロセスの階層構造あるいは構成要素を定義するには、ちょっとした工夫が必要である。込 
み入ったものを複数の構成要素に分解するには、つねにさまざまな方法が考えられる。最良の 
方法は、マニュアルを「使いやすさ」の極みにまで高めること、つまり、読飛ばしや枝分かれ 
や逆戻りの回数をなるべく減らすことである。 
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8.5 経験者のためのモジュールを設計する 

8.5.1 例:管理者のためのデモンストレーション•モジ!ール 


下記の例は、軍需品管理システムのためのオペレーション.マニュアルから抜粋したもので 
ある（私が書いたものではない ）0 この例は、特定のコマンドの使い方を示すものだが、前もつ 
て充分なオリエンテーションを行なうことを前提にしている0このモジュールは要約部分を付 
け加えることで、ガラツと生まれ変わるだろう。 


MI 

マスター 在庫調査 

目的： 

MI トランザクションは、以下の者が使用するよう設計されている。 
• 在庫管理担当者 
• 各基地の倉庫担当者 
• 各基地の保守用具管理 （ MMC ) 担当者 
MI トランザクションの使用目的は、以下の通り。 

•手持ち在庫品目のチェック 

•各品目が保管されている補給機関（會庫）のチェック 
• 総合在庫情報チェック 
使用するデータベース： 

• MSDB - マスター サプライ •データベース 
使用可能なトランザクション•モード： 

• 6 (検索用） 

必要なトランザクション • キー： 

• 部品番号 .（32 文字） 

•メー カーコード .（5 文字） 

•または、在庫登録番号 .（9 文字） 

エラーメッセージ： 


100 1— 在庫登録番号入力されたものが見つかりません。 

1002— 部品番号 • 製造者コード入力されたものが見つかりませんーチヱックには XP トラ 
ンザクションをイ吏用してください。 

1003— 部品番号 • 製造者コードまたは在庫登録番号を入力してください。 

1004— 入力した部品番号 • メーカーコード用に多重在庫登録番号あり一必要な在庫登録番号 
を決めるには、 XP トランザクションを使用のこと一在庫登録番号でトランザクショ 
ンを再入力してください。 

1005— 登録されていない部品番号は入力できません。 

1408 —補給機関無効ーデータディクショナリを参照 

一補給機関の表示終了 

—補給機関リストの次ページを見る場合は、 ENTER キーを押してください。 
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図表 8.5.1 


Ml の画面 
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マニュアルへの 構造的 アプローチ 


日. 5経験者のためのモジュールを設計する 

8_ 5. 2例:企画者のためのデモンストレーシヨン•モジ:2—ル 


下記の例は、 コミュニケーション•プランニング•マニュアルからの 抜粋である（私が書い 
たものではない）。これは、企画者 （プランナー） が1つの領域の境界線をどのように定義およ 
び再定義するかを示すものである。 


5. 領域を定義する 
5.1 領域の再定義 

1つの領域を2つに、2つの領域を1つに、という具合に、既存の領域をいく通りかに定義し直 
すことができます。また座標や辺も変更することができます。 


追加したり、削除したり、変更したりすることで、領域を定義し直すことができます。この 
場合、システムが以下の情報を入力するよう求めてきます。 

入力装置：デジタイザーかキーボードか 
更新の種類：追加、変更、削除のどれか 
領域更新/座標更新：全座標か一部の座標か 
対象領域：再定義の対象となる領域 

領域更新 

座標を入力できます。作業を終了するときは、デジタイザーから “ g ”、 またはキー 
ボードからを入力してください。 

変更 :追加と同じ手順です。新しい座標が古い座標に書き換えられて記録されます。 

削除 :マスターファイルから指定された領域が削除されます。 

座標更新 

追加：現在の座標が表示されますので、追力卩したい座標を指定すると、その座標が表示中 
の座標の後に追加されます。 

銮 M :変更すべき座標を指定し、次に新しい座標を指定します。新しい座標は古い座標に 
書き換えられて記録されます。 

型途：削除すべき座標を指定します。指定を確認すると、その座標は削除され、後の座標 
がすべて繰り上がります。 


注：領域が再定義されると、システムは必ず影響を受けるすべての構築物、各線分を結ぶ 
点、端点の割りあてをやり直します。 
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更新前の領域 

点 1 から点 5 によって定義されている 



1点を変更する 

新しい座標を点 3 に割りあてる 



1点を加える 

新しい点を点 3 と点 4 の間に挿入する 


1点を削除する 

領域の定義から点 3 を削除する 


図表 8.5.2 領域変更の3つの方法 
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マニュアルへの 構造的 アプローチ 


日. 6効果的なリファレンス•モジュールを設計する 


モジュール 化の形式からはあまり効果の期待できない マニュアルの タイプもある。その筆頭 
はリファレンスだろう0つまり必要に応じて“参照する’’一覧表、目録、明細書などである。 

リファレンスの部分を各モジュールに分解すべきか否かを決定する上での唯一の判断基準は、 
そうしたモジュール化が内容を見つけやすく、使いやすいものにするかどうかということであ 
る0もし内容をぶつ切りにしたり、寄せ集めたりすることが、リファレンスのもつ機能を助け 
ることにならないのなら、モジュール化はやめた方がよい。 


•電話帳をモジュール化するメリツトは7 

リファレンス•モジュールはリファレンス（参照） を行なうためのものである。初心者教育 
や動機付けやデ モンストレーシヨンの ためのものではない。リ ファレンスの 役割は、 ューザー 
の記憶の代わりをすることである。 つまり、誰もわざわざ記憶にとどめようとはしないような 
項目のリストにうってつけの場所を提供するか、あるいは以前に解説されて以来、人が忘れて 
いるような項目を探しやすいようにすることである。 

図表 8.6 が示すように、単独あるいは複数のリファレンス•モジュールを作成するための最初 
の作業は、“標準的”なリファレンスの提示の仕方、すなわち長いリストや目録を表示する典型 
的な方法が適当かどうかを評価することである。リストは、ワープロ打ちの原稿そのままで“ひ 
とまとめ”にすべきだろうか、それとも、モジュール化する必要があるだろうか。たとえば、 
もっとも身近なリファレンスの記述内容一電話番号簿のような一を2ページのモジュールに書 
き換えることに何かメリットがあるだろうか。 



図表 8.6 < 効果的なリファレンス.モジュールを設計する> 
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多くの場合、何もメリットはない。かつて“論理的にグループ分けされた” リファレンス. 
リストを見たことがあるが、読者側の使い勝手からすると、逆効果のようだった。たとえば、 
ある マニュアルでは、 エラーメッセー ジにコ ード番号が付けられ、オペレーター の ミスによっ 
て起こったエラーと、システムの動作不良によって起こったエラーとに分けられていた。この 
場合、残念ながらオペレーターは、画面に現われたものを見て、どちらに分類されるエラーか 
分からず、結局「両方」の場所を探すことになってしまうだろう。 

•リファレンス • モジュールはどこにどろ置かれるべきか 

出来のよいリファレンス•モジュールは人に何かを教えようとは「しない」。このモジュール 
の特徴の1つは、ヘッドライン、要約などが非常に短く、また、しばしば「要約のほかにはテキ 
ストが何もない」、ということである。リファレンス•モジュールの典型的なものには、完成時 
において、2ぺージにわたる図表（チャート、テーブル、リストなど）が含まれることが多い。 

リファレンス 部分の記述内容が多い マニュアルーモジュール 化されているいないにかかわら 
ず一は、あまり効果的な マニュアルとは いえないだろう。 リファレンスとは、ューザー が シス 
テムあるいは製品の動かし方を知った「後」で、必要とされるものである。それまでは、 リファ 
レンスの 記述内容は、 ューザーに とってあまり親切なものではなく、 ューザーが 読むのをため 
らうものでさえある。 

リファレンス的な記述内容を増やすような方針の恐ろしいところは、「用語解説で説明を済ま 
せ」ようとすることである。たとえば、あるマニュアルを、あるューザー（仮称 U ) にあてて 
書いたとしよう。この場合、新しい用語を導人するたびに、用語解説（たぶんマニュアルの前 
か後ろかにある）を参照することを強要してはならない。用語解説は、チュートリアルやデモ 
ンストレーション•モジュールの中で習ったことを「思い出す」場合に役立つものである。読 
者に用語解説を參照させたり、あるいは、読者が頻繁に用語解説を見ることを想定したりする 
ことは、そのマニュアルが他の誰かのために設計されたものであると読者に思わせることであ 
る。 

リファレンス•モジュールは、 単独では何も教えることはできない。 また、 何かを教える た 

めの記述の部分に組み込まれるべきでもない。 ューザーにとって、頻繁に使う表を見つけるた 
めに、チュートリアル.セクションをいちいち探すのは面倒なことである。 

したがって、リファレンス•モジュールは、すぐに探せる場所にあるべきである。マニュア 
ルの最初か最後、あるいはバインダーのカバーの部分でも構わない。ポスターや折込みや“参 
照しやすい”ようにポケットサ4ズに折りたためるようなページなどの形を取ることもできる。 
オペレーターはよく自分でリファレンスを作り、ノートに保管するか、入力装置の脇にテープ 
で貼り付けるかしている。 

もし ューザー やオペレーターが、 「自分自身」のリファレンス•マニュアルを 作っているとし 
たら一そしてもし、われわれが リファレンス.マニュアルの 正確さと メンテナンスの しやすさ 
を望んでいるなら一彼らが必要としているものが何かをつきとめ、それを彼らに提供すべきで 
ある。 
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日 . B 効果的なリファレンス•モジュールを設計する 

8. B . 1例：管理職のためのリファレンス•モジ z —ル 


下記は、大規模メーカー向けの電子メール • システムのエンドユーザー.ガイドから抜粋し 
たものである（私が書いたものではない ）0 これは、全体を概観したり、記憶する助けにはなる 
が、それ自体は何かを指導したり、実演（デモンストレーション）してみせたりしないことに 
注意して欲しい。システムの使い方を知っている者だけが、この表を使うことができる。（また、 
このモジュールは、1ページに収められたことにも注意すること。） 


M AIL システムでどんなコマンドカぐ使えるか？ 


MAIL システムで使用される基本的なコマンドはいくつかありますーユーザーは、送られて 
きた MAIL メッセージを読んだり、他のユーザーにメッセージを送ったり、古いメッセージを 
削除したりできます。各コマンドについては、それぞれ別に後述します。 


MAIL システムを使うには、読取り、送信などのコマンドをキーインし、く RETURN 〉 キー 
を押します。コマンドは必ず MAIL 〉 プロンプト時にキーインします。 


図表 8.6.1 
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MAIL コマンドー 覧 

コマンド 

意味 

BACK 

ディレクトリ内の1つ前のメッセージを表示する。 

DELETE 

一番最後に表示したメッセージを削除する。 

DIRECTORY 

メッセージー覧表を作る。 

EXIT 

MAIL 操作をやめる。 

FILE 

最後に表示されたメッセージを特定ファイルにコピーする。 

FORWARD 

最後に表示されたメッセージを他のユーザーに送る。 

HELP 

MAIL の使い方についての情報を表示する。 

NEXT 

現在表示中のメッセージの途中から飛んで、ディレクトリ内の 

次のメッセージを表示する。 

QUIT 

実行した削除をキャンセルし、 MAIL 操作をやめる。この場合、 

ディレクトリは正確に MAIL 操作に入ったときの状態になって 

いる。 

READ 

ディレクトリ内の次のメッセージまたは現在表示されているメ 

ッセージの次の画面を表示する（〈円巳丁リ円[\1〉キーを押しても 

READ と同じ効果)。 

READ MAIL 

MAIL システム操作中に受け取った新しいメッセージを表示す 

る。 

REPLY 

最後に表示されたメッセージの送り手に、同じテーマについて 

のメッセージを送る。 

SEARCH 

指定された記述内容を含むメッセージを探し、表示する。 

SEND 

メッセージを他のユーザーに送る。 

SEND / し AS 丁 

今送ったばかりのメッセージのコピーを別のユーザーに送る。 
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8.6 効果的なリファレンス•モジュールを設計する 

8. &2例：一般社員のためのリファレンス•モジ！ール 


以下は、商用ソフトの導入マニュアルからの抜粋である（私が書いたものではない ）0 これに 
は、同じシステムの使い方をどこかで習ったことのあるワープロ.オペレーターなどに便利な 
コマンドの機能一覧が付いている。 


10. RUNOFF ワードプロセッサー 

10.2 コマンドの定義 


RUNOFF は、実ファイル項目に登録された情報を処理するものである。この情報は、テキス 
卜と RUNOFF コマンドからなっている。 


RUNOFF コマンドは、必ずピリオド （•） を先頭に付けて使用する。コマンドを使用した行に 
はテキストを含めてはならない（すなわち、コマンドがテキスト行に現われることはない）。複 
数のコマンドを1行に並べることもできる。 

RUNOFF は、情報を2つの方法のうちの1つで処理する。“充塡”モードでは、その行にそれ以 
上単語が入らなくなるまで、一度に単語がプリントされる。マージン調整オプションがある場 
合には、単語間にアットランダムにスペースが追加され、右マージンの調整が 1亍なわれる。こ 
のモードは、センテンス形式のテキストによく使われる（今読者が読んでいる文章は、“充塡” 
と“マージン調整’’の2つのモードで処理されたものである）。このモードを使えば、行末を気 
にせず、自由にテキストを入力することができる。“非充塡”コードでは、項目単位で1行が処 
理される。このモードは主として、図表処理用に使われている（このマニュアルの右ページの 
ほとんどがそれである）。 

図表 A は RUNOFF コマンドの簡単な一覧表である。図表 B はこのページを構成している 
項目の割付表である。 


BEGIN PAGE (.巳 P ) 

BREAKCB ) 

CAPITALIZE SENTENCES (. CS ) 
CENTERCC ) 

CHAINGDICT ) ファイル名項目コード) 

CHAPTER title 

CONTENTS 

CRT 

FILL (. F ) 

FOOTING 
HEADING 
INDENT N (. In ) 

INDENT MARGINC IMn ) 


巳 REAK 処理し、改ページする。 

次行を処理する前に一部だけいっぱいになった行を出 
力する。 

各文の最初の単語を大文字にする。 

指定されたテキスト行を中央に持ってくる。 

指定されたテキストファイルにつなげる。 

章の見出しの番号を付け、フォーマットを決める。 
CHAPTER コマンドおよび SECTION コマンドの 
実行によって累積した目次を印刷する。 

ユーザーの端末への出力を指定する。 

はみ出しがないよろにして行を埋める。 

各ページの最後に指定行を印刷する。 

各ページの頭に指定行を印刷する。 

指定行を’ n ’ スペース分頭下げする。 

左マージンの位置決めをする。 
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INDEX text 
INPUT 

JUSTIFY (. J ) 

LEFT MARGIN n 
LINE LENGTH n 
LOWER CASE 

LPT 闩 

NOCAPITALIZE SENTENCESC NCS ) 
NOFILL 

NOJUSTIFYC NJ ) 

PAGENUM 巳 ER n 
PARAGRAPH (. Pn ) 

PRINT INDEX 

PRINT 

READ ({ DIC ~ n ファイル名項目コード） 
SECTION level title 
SET TABS n { n }... 

SKIP n(.SK n ) 

SPACING n 
STANDARD 
UPPER CASEC UC ) 


インデックス•リストに“テキスト”を登録する。 
端末から指定行を読む。 

右マージンの位置決めをする。 

左マージンをセットする。 

行の長さをセットする。 

(指定されたものを除く）すべての文字を小文字で出力 
する。 

システム • プリンターに出力命令を出す。 
CAPITALIZE SENTENCES モードを解除する。 
FILL モードを解除する。 

JUSTIFY モードを解除する。 

現在のページ番号をセットする。 

(最初の行を頭下げして）テキストをパラグラフにまと 
める。 

INDEX コマンドで作成され、ソートされた見出し語 
を印刷する。 

ユーザーの端末に指定行を表示する。 

指定されたテキスト項目を読み取り、処理する。 

' n * レベル下げて次項の番号を付ける。 

タブ位置をセットする。 

’门’行分の空白を印刷する。 

行間隔をセットする。 

デフオルトパラメータを解除す る。 

文字をそのまま（大文字または小文字で)印刷する。 


図表 A . RUNOFF コマンドー*览 


001 BP 
002 . F . J 

003 .READ FOOTING . L 

004 . INDEX ’ RUN 〇 FF コマンドの定義’ 

005 .SECTION 8コマンドの定義 
006 . SK P 

007 RUNOFF は、実ファイル項目に登録された情報を処理するものである。 
008この情報は、テキストと RUNOFF コマンドからなつている。 

009 .SK 2 010 

010 RUNOFF コマンドは、必ずピリオド （•） を先頭に付けて使用する。 

011コマンドを使用した行にはテキストを含めてはならない（すなわち、コマ 
01 P ンドがテキスト行に現われることはない)。 

013複数のコマンドを1行に並べることもできる。 

014 .SK 

015 RUNOFF は、情報を2つの方法のうちの1つで処理する。 

016 “充填”モードでは、その行にそれ以上単語が入らなくなるまで、一度に 
017単語がプリントされる。 

018マージン調整オプションがある場合には、単語間にアツトランダムにスぺ 
019 —スが追加され、右マージンの調整が行なわれる。 

0 P 0 このモードは、センテンス形式のテキストによく使われる（今読者が読ん 
021でいる文章は、“充填”と“マージン調整”の2つのモードで処理された 
0 P 2 ものである）。 

0 P 3 このモードを使えば、行末を気にせず、自由にテキストを入力することが 
m でぎる0 

025 “非充填”コードでは、項目単位で1行が処理される。 

026このモードは主として、図表処理用に使われている（このマニュアルの右 
027ページのほとんどがそれである)。 


図表巳. RUNOFF 項目;别付サンプル 
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8. 7ストーリーボードをピンナップする 


モジュールの スペックは、まだ山積みにされている状態である。このままではテストするに 
も、手を加えるにも、何の機能も果たさない0そこで次のステップは、このスペックの山を壁 
に貼り、スペックの“ギヤラリー”あるいは“ストーリーボード”を作成することである。こ 
のようにしてスペックは、それを書いた“執筆者’’、出来上がった マニュアルを 読むことになる 
読者、そして組織内の役員も含めた人々によって見直され、訂正されることになる。 


•モジュールのギヤラリーを歩く 

個々のモジュール•スペックは、一番よい順序で部屋の壁に貼られることによって、“ギャラ 
リー’’に作り変えられる。マニュアルのアウトラインを目で見える形にするというこのプロセ 
スは、一般的に“ストーリーボード作業”と呼ばれる。これは映画産業から持ってきた用語で 
ある。（おもしろいことに、映画製作向けの技術を用いると、マニュアル作成者にとって、マニュ 
アルというものは、情報の「階層的」集合というより、情報の「連続」と考えられるようにな 
る。) 

このようにして初めて、スペックを書いた1人あるいは2人は、実際にそれを見ることができ 
る。彼らは互いに質問を交わしながら、ギャラリーを“ウォークスルー*”し、各モジュールの 
強調すべき点や守備範囲、順序を検討する。 

次に“執筆者”一本文や図表の抜けている部分を書き足す人たち一を招待して、ストーリー 
ボードを見直してもらい、一層掘り下げた修正や示唆をしてもらう。 

企画者と書き手が納得すれば、次にストーリーボードをューザーの目から批評してもらう。 
あらためて、実際のューザー、あるいはューザーの事情がよく分かっている人が、ストーリー 
ボードを見直して、明快かどうか、読みやすい並び方かどうか、適切かどうかを調べる。 

ューザー や オペレーター （または その 代弁者） がストーリーボー ドを見直しているときには、 
マニュアル 企画者は立ち会うべきである。質問が なされれば、 企画は明快になり、一貫性が出 
てくる。また、対象となる読者が実際に何を知っているか、あるいは何を行なうかについての 
誤解を正すこと もで きる。 マニュアルのストーリーボード•バージョンが、システム 開発の ご 
く早い時期に用意 されれば、システムの 企画の改善方法を見つけ出すことが、事実可能である。 
籲体の動きに注目せよ 

マニュアル設計者は、ユーザーやその他の読者がプランを見直している間、彼らを「観察」 


モジュール* 

スペック 


図 


モジュール- 

スペック 

2.0 


図 


モジュール* 

スペック 

2.1 


図 


モジュール • 
スペック 
2.2 


図 


図表 8.7 < モジュール.スぺックの“ギャラリー”〉 
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することが大切である。構造化されたプログラミングやその見直し、というような比喩的な意 
味の探索とは違って、ストーリーボードを使うと、関係者は文字通りマニュアルのモデルを 
「ウォークスルー」させられることになる。そして、マニュアルの設計者は、見直す人たちの（目 
や足などの）身体的な動きをただ見るだけで、設計上の欠陥を見分けることができる。設計の 
この段階でも、オペレーターやユーザーがマニュアルの論理性を追いかけるところを設計者が 
観察すれば、一貫性のなさ一読み返しや回り道一が明白になってくる。まだ変更が容易なうち 
に、最悪の設計ミスや、まったく信頼性のない個所が明らかになる。 

•1 つのモデルは1ヶ所に 

ストーリーボードを作成して、それを最大限有効に活用するためには、「1つ」のストーリー 

ボード•モデルを「1つの場所」に貼るのがよい。 会社の規模が小さく、どうしても専門の部屋 
を取るのが難しい場合を別にすれば、ほとんどの会社ではこれは問題ないだろう。しかし、会 
社の規模がもっと大きくなると、出来上がったマニュアルに関心を持つさまざまな見直し役は、 
数ヶ所に分かれて作業をすることになる。最大手の企業になると、マニュアル作成部門が、開 
発者や ユーザーから 数千マイル離れている、ということもあり得る。 

場所の問題については同情するが、それでも「1つの」モデルを「1ヶ所」に、ということを 
勧める。原則としては、どのような技術出版物に関しても、複数の見直し原稿を作らない、ま 
た原稿を郵送しない、ということを勧める。私の体験した技術文書の見直し作業のうち、唯一 
完全なものは、関係者全員の在席のもとに、多くの質問や討論を繰り返し、必要な人とデータ 
を脇に置いてなされた。 

有意義な変更がすべて取り入れられて、最終的に設計者たちが満足すれば、最後にその設計 
案に署名し、企業の役員（または役員会）を呼んで、ストーリーボードを見直してもらう。設 
計案が承認されれば、それはそのまま「凍結」する。極端な例外を除いて、変更はいっさい認 
められない。モジュールの内部での変更ということ以外は、提案された変更が1つ以上のモ 
ジュールに影響するようであれば、再びストーリーボードに戻る。 


訳注*ウォークスルー： walkthrough 。 プログラム開発を効果的に進める技法の1つ。開発プロセスが独善的 
にならぬよう、プロセス全体に対し、各担当者が、一定の基準やルールに従って何度も見直しする。 
本書全体がいわばマニュアル作成のウォークスルーを指南したものといっても過言ではないだろう。 
ただしウォークスルーは設計の妥当性を再検討することであり、修正ではないことに注意。 
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8.日ストーリーボードを変更する 


構造化設計や映画の構想作りなどにも見られるように、モジュールのストーリーボードを作 
成することの最大の利点は、それを使うと変更が簡単であるということだ0アウトラインの中 
に見出される、全範囲に渡る技術的な欠陥やコミュニケーションの方法に関する欠陥が、比較 
的わずかな“場所の移動”によってはっきりしてしまう、というのは皮肉な話だ0あまり通り 
たくない悪路一つまり読者を GOTO に送り出すような個所（回り道、複雑にからみ合った環状 
の筋道、始まったとたんに終わってしまうようなもの）一は、モジュールのスペックを操作す 
るだけで、発見し修正することができる。 


•ストーリーボードを見直す基準 

ストーリーボードは「テスト」であり、テストにはすべて標準形式と評価基準がある、とい 
うことを忘れてはならない。 マニュアルの 循環や迂回の数一いわゆる GOTO - を抑えなくては 
ならないと、すでに繰り返し強調してきた。このような大ざっぱな考え方や制約で充分な場合 
もある。なぜなら、あまり厳密さを要求されない見直し作業では、目標は定められた標準形式 
に達することではなく、見直す人たちを納得させればすむからである。 

しかし厳密な ルールに のっとった見直しでは、何ら かの はっきりした評価基準が必要である。 
設計や手順を“最高”のものにしたいときはなおさらである。中心となる基準として、次の定 
義を提案したい。 

「 GOTO なきマニュアル」では、読者は読み始めれば、そのまま「読み終わる」はずである。 
それ以上の情報が必要だったり、読みたいと思ったときは、別のモジュールの初めに移ればよ 
い。そしてそれを読み終えればよい。さらにいえば、たいていの場合、2番目のモジュールは、 
1番目のが終わったすぐ後に続けられるのが普通である。 

要するに、このような制約があれば、マニュアル作成者やテクニカルライターは、読者がモ 
ジュールを中途で抜け出したり、モジュールに中途から入ったりすることのないよう、気を配 
るようになる。特に、あるモジュールの中途から他のモジュールの中途に移らせ、その後、最 
初のモジュールの出口に戻らせる、というようなことをしなくなる。 

さて、先に マニュアルの “分割”について論じてすでに明らかにしたことであるが、ある特 
定の マニュアルの 読者が多様であればあるほど、読者がその マニュアルを どのように使用する 
かを予測するのは難しくなる。したがって原則的には、すべての読者を対象として、上に定義 
したような基準を満たす マニュアルを 開発するのは不可能である。そして読者の多様性が著し 
くなればなるほど、基準の達成は難しくなる。 

しかし、出来上がりのマニュアルが、できるだけこの基準に近づくように、モジュール•ス 
ペックを作り直し、配列し直すのがマニュアル設計者の仕事である。 適切とはいえない個所で 
読者がモジュールから出たり、モジュールに入ったりせざるを得なくなるたびに、_設計の変更 


を試みるべきだ。（第一稿を書き終わった後では遅すぎる。） 
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図表 8.8 < ストーリーボードを変更する〉 

_ストーリーボードの変更テクニック 

モジュール•スペックのごくわずかな“移動”だけで、非常に込み入った変更ができるのに 
は驚く。 


解体一1つのモジュールを、列または階層ごとに、2つ以上のモジュールに変換する。それぞ 
れのモジュ'—ノレに新しいスぺックを付ける。 

統合一同じ論点または概念であれば、2つ以上のモジュールを1つにする。 

挿入ーギャップを埋めるために、1つまたはそれ以上のモジュールを追力卩（揷入）する。 

削除一“論理性”から“読みやすさ”へという趣旨で、モジュールを取り除く。 

再配置一1つのモジュールまたはモジュール群を、同一^マニュアル内で移動させる。 

繰り返していうと、これらの“移動”で、可能な変更のほとんどの説明がつく。（モジュール 
「内」での変更ということもある。モジュール•スペックの内容をほんの少し変えるか、強調の 
ために注釈を追加する、といった方法だ。） 

ストーリーボードは、変更や改訂のプロセスを容易にするために作り出されたテクニックで 
ある。ストーリーボードのプランは、1日に何十回も根本的に改訂することができる。しかし、 
第一稿が完全に出来上がってしまうと、つぎはぎや詰め物で修繕はできるが、根本的に設計を 
し直して、欠点を取り除くことは絶対にできない。 
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マニュアルへの構造的アプローチ 


8.9 Redundancy は排除されるべきか 


皮肉なことに、モジュール化されたマニュアルが成功するか否かを確かめる目安の1つは、読 
者が redundancy に気付く 一あるいはときに文句をいう一かどうかである 0 複数のモジュール 
間にまたがる redundancy は、枝分かれ、逆戻り、回り道などの必要を緩和してくれる。また、 
モジュール内部の redundancy は、読みにくさや読み落としなどを補ってくれるものである 0 


籲 redundancy とは何力、 

いくぶん呑み込みやすくするために、 redundancy 以外の言葉を使うことができたかもしれ 
ない： 

たとえば、繰返し、敷衍、念押し、言い直しなど。 

しかし、 redundancy とは何だろう 0 それは必要以上に用いること、必要以上に消費すること、 
同じような情報を3回4回5回と書くこと、つまり同じ節、段落、図表を使うことなどである。実 
際、マニュアルを作成する上で問題が起こった場合、同じ論題を違った言葉や図で説明するよ 
りも、同じ説明を繰り返す方がよい。 

使いやすいマニュアルの redundancy には2種類ある。モジュール間にまたがるものと、1つの 
モジュールの中で現われるものの2つである。図表 8.9 では、モジュール間にまたがる redun ¬ 
dancy の単純な ものを示している。 いろいろな操作を 始める前に、 しなくてはならない手順とい 
うものがある。 redundancy のないマニュアルの場合、読者は何度も冒頭の手順に戻らなくては 
ならない。（タスク B の進め方を習う前に、タスク A のところを読むよう指示され、 C 、 D 、 E 、 
F . • •についても同様の指示が繰り返される。）それに引き換え、 redundancy のあるマニユア 
ルでは、後の操作の個所でも、最初の手順の説明が、決められた表現で繰り返されている。 こ 

の方法は、たとえば計算機のマニュアルなどでよく使われる。計算機のマニュアルの場合、そ 
れぞれの操作を始めるとき、計算機を立ち上げたり、登録を消去する場合の注意書きが付け加 
えられる。 

鲁プ□クラ厶の redu 门 da 门 cy とマニユアノレの redundancy 

マニュアルに redundancy を取り入れるべきか否かの問題は複雑で、議論の的になるとこ 
ろだ。特に興味深いのは、 redundancy を取り人れると、モジュール化されたコンピュータ. 
プログラムとモジュール化されたマニュアルの類似性が破壊される、という議論だ。ある見方 
によれば、構造化されたプログラムの基本は、プログラムになるべく redundancy が「ない」、 
というものだ。つまり、ある特定の作業あるいは機能が必要になるたびに、プログラムの中の 
特定の場所から、それらを呼び出すわけである。 


「日 dundancy のないモジュール設計： 


redundancy のあるモジュール設計： 



図表 8.9 くモジュール間の redundancy 〉 
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しかし、もっと綿密に検討すると、類似性はやはり存在する。本当の問題は、 ユーザーのた 
めに作ったマニュアルが、ユーザーのために実行される“呼出し”をすベて備えているかどう 

左!、すなわち読者が適当なモジュールを探し出して、適当なときにそれを役立てられると思っ 
てよいのかどうか、ということである。そうした判断を下すときの材料となる要因も類似して 
いる。繰返し部分がかなり長い場合には、それを各モジュールごとに繰り返すのは好ましくな 
い。また、何度もその説明部分を呼び出したり、参照しなくてはならないとなると、読み進む 
プロセスが複雑になり、難しくなる。それはたび重なる呼出しが、コンピュータ•プログラム 
を複雑にするのと同じである。 

•redundancy は何の役に立つか 

redundancy は、メンテナンスを複雑にし、役に立たず、無駄であるように見えるが、マニュ 
アルの中の読飛ばし、枝分かれ、逆戻りの数を減らしてくれる。マニュアルを読み慣れていな 
い読者には、 redundancy があるかないかで、読みやすいか、読みにくいかが違ってくる。また 
反対に、複雑なマニュアルを読みこなすことのできる熟練ユーザー向けのものには、あまり 
redundancy を入れない方が無難であると、マニュアル作成者に気付かせることになるかもし 
れない。 

(redundancy が多すぎると煩雑になることがある0指示があまり頻繁に繰り返されると、説 
教のように感じられる。たとえば、本書に見られるような繰返しの数は、プロの読者向けのテ 
キストよりも、ユーザー•マニュアルに適している。先にも触れたが、これは私の勧める方法 
を実証したいがためである。） 

モジュール間の redundancy については、「まったく同じ」繰返しを用いるべきである。たと 
えば繰り返される段落や図をワープロに登録しておけば、正確にコピーできるようになるし、 
また1ヶ所を変更すると、それを繰り返すところすべてを変更できるようにもなる。 

逆に、モジュール内での redundancy は、繰返しを少なくして、等価値の説明を増やすとよい0 
2ページ（見開き1ページ）のモジュールのほとんどが、「3つの」 redundancy のブロックを持っ 
ている。つまり、ヘッドライン/要約、図表、そして詳しい記述の本文一これらすべては、互 
いに補強し、重なり合っている。 
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8.10枝分かれと階層構造を操作する 


独立した個々のモジュールを順番に結び合わせたものとしてマニュアルを設計することは、 
非論理的だろうか？ 枝分かれする部分や階層構造に関しては、どう扱えばよいか？ あるい 
はまた、1つのモジュールに入り切らない長くて複雑なプロセスに関してはどうだろうか？ 


•モジュールを階層化する 

ある一定の因果関係にもとづく伝達方法一概念や説明が同一階層（レベル）上に並び、段組 
みも従属関係もない一はもっとも明快で、もっとも効果的である。短いトレーニング•ガイド、 
マーケティング用のパンフレット、20分ほどの映像などによるちょっとした報告、簡単にまと 
めた提案書一このような短く簡潔な伝達方法は、議論がなかなか進展しなかったり、売上げが 
頭打ちになっていたりする状態を一気に打開するためのはずみ車となったとき、もっともその 
効力を発揮する。マニュアルもこのように作ることができるはずであるから、こうした伝達方 
法同様、もっと効果的になるはずである。 

しかし、膨大なページを要する表や定義や処理手順(枝分かれや逆戻りのあるプロセス）など 
を含む、より複雑なテクニカル.マニュアルやリファレンス.マニュアルに関してはどうか？ 

まったく問題はない。必要に応じて各ヘッドラインの頭を引っ込めたり、階層が分かるよう 
に番号をふったりといった簡単な方法で、階層構造は残したまま、読者にょり明確なものにす 
ることができる。たとえば、あるモジュールが前のモジュールの“レベル”より上にあるか、 
下にあるか、同じであるかは、そのモジュールのヘディングを見るだけでも明確になる。また、 
そのモジュールの最初に出てくる情報を見ると、そのモジュールの“1つ上のレベル”は何か、 
ということが分かる一これは従来のマニュアルでは、目次を見なければどこにも出てこないも 
のである。（たとえばあなたは今、第8章という大見出しの、1つ下のレベルのモジュールを読ん 
でいることになる。）モジュール化されたマニュアルは、「それぞれのモジュールの中で」、その 
マニュアルの階層と構成を見せてくれるのだ！ 

図表8.10にあるように、モジュール化されたマニュアルの目次は、連続型か階層型のどちら 
かである。左側の階層型のものは、2段階式で段組み処理を行なっている。右側のものは3段階 
式で、おなじみの小数点方式の表記を行なっている。実際、モジュール化の手法では、1つ1つ 
の操作手順をあまり長くならないよう制限することによって、階層構造が「必然的に出来上が 
る」ことが多い。 

•枝分かれを5まく処理する 

モジュール化の手法では、操作手順が途中で「枝分かれ」していく場合にも、うまく説明する 
ことができる。枝分かれとは、オペレーターの選択によって、あるいはシステムがそのときの 
都合に応じて、2つ以上の代替経路のうちの1つに向かう行為である。従来のマニュアルでは、 
こうした枝分かれは、作成の過程において、もっとも複雑で油断のならない瞬間である。モ 
ジュール化されたマニュアルでは、最良の対処方法は、 1つのモジュールの中に、代替経路を 
含んだ操作手順全体を詰め込んでしまう ことである。1つのモジュールにうまく入らない場合 
は、 モジュールの「終わりを枝分かれする地点に」持ってくる のがよいだろう。つまり読者 
は、次の代替モジュールの一方に進んで、もとのところに戻る必要がなくなるのだ。それは読ま 
なくてよい何ページかの存在を意味し、並列の経路についての redundancy を意味する。 

マニュアルの設計を構造化すれば、ライターは、マニュアルを報告書や提案書として扱うよ 
うになるだろう。なぜならそこでは、各モジュールがもっとも効果的で使いやすい順番に並ん 
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でいるからである。 


連続型（単一階層）アウトライン 


添付ディスクをコピーする 
システムにハードの機種を登録する 
オプシヨンその他を選択する 
住所録を準備する 
住所録へデータを入力する 
住所録のデータを蛮更する 

他の住所録の一部から新しい住所録を作る 

住所録全体を印刷する 

住所録の一■部を印刷する 

封筒を印刷する 

ラベルを印刷する 

トラブル対策チャート 

階層型 （2 階層）アウトライン 

階層型 （3 階層）アウトライン 

スタートの4つのステップ 
添付ディスクをコピーする 
システムにハードの機種を登録する 
オプシヨンその他を選択する 
住所録を準備する 
住所を入力する3つの方法 
住所録への最初のデータ人力 
住所録の旧データの変更 
他の住所録の一部から新しい住所録を作る 
住所録を印刷する 

印刷すべき住所を選択する 
封筒を印刷する 
ラベルを印刷する 
トラブル対策チャート 

1. スタートの4つのステップ 

1.1 添付ディスクをコピーする 

1.2 オプシヨンと初期値を設定する 

1.2.1 システムにハードの機棟を登録 
する 

1.2.2 オプシヨンその他を選択する 
1.2.3 住所録を準備する 

2. 住所録を作るさまざまな方法 

2.1 キーボー ドからデータを入力する 
2.1.1 住所録への最初のデータ入力 
2.1.2 住所録の旧データの変更 

2.2 既存ファイルのデータを利用する 
2.2.1 他の住所録の一部から新しい住 
所録を作る 

2.2.2 他のデータべース内の住所録を 
利用する 

3. 住所録を印刷する 

3.1 印刷すべき住所を選択する 

3.2 封筒を印刷する 

3.3 ラベルを印刷する 
付録：トラブル対策チャート 


図表8.10 
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マニュアルへの構造的アプローチ 


9. 1 “ GOTO ” なき設計の有効性 


GOTO なきマニュアルから利益を得るのは、まず第一に読者である0しかし、マニュアルを 
作成する側にとっても、 GOTO がないということの意義は大きい 0 GOTO なき設計によって、 
モジュール相互間の独立性が保証され、そのためモジュールをどのような順番で書くことも、 

“執筆者’，をどのように割りあてることも可能になるのである。それだけではなく、モジュール 
をその相互関係から切り離して、個々に見直し、テストすることもできるようになる0 


籲 G 〇 TO なきマニュアルとは何か 

前述したように、“設計を凍結させる”とは、マニュアルの設計をもはや変えることが「でき 
ない」という意味ではない。設計とは、既定のルールを前提としており、したがって、その設 
計を変更する場合には、このルールに準じた一定の手順で行なわなければならないということ 
を意味する。どんな小さな変更であろうと、 「 GOTO なき設計」を損ない、その変更作業の途中 
で、モジュール相互の独立性をおびやかすようなものであってはならない。 

GOTO なきマニュアルとは、モジュールの集合体であり、モジュール相互間で考え得るあら 
ゆるつながり一参照関係一は、そうした集合体の設計案の中で確認することができる。目的の 
モジュールの内部へと、うまく読者を導き得ないとしたら、その原因を突きとめなければなら 
ないのは、ほかでもない、その問題のモジュールを書いているライター本人である。 A という 
ライターが、 B というライターのモジュールについて知 っておかねばならないことは、すでに 
「ストーリーボード」の中、「モジュール•スペ ック」の中に示されている。 

しかし、このモジュール相互の機能の独立性は、もし誰かがストーリーボード作業をやり直 
さずに、もとの設計から逸脱したり、もとの設計に追加したりすると、一瞬のうちに崩壊して 
しまう。 （1 個のモジュールの枠内に完全に収まり、他のモジュールに影響を与えないような変 
更については、もちろん何の問題もない。一般的にいって、ヘッドラインや要約部分に変更を 
必要としないようなモジュールの変更は、ライターの裁量に任される。） 

籲モジュールは自己完結している 

さらに、もし GOTO なきロジックを徹底できれば、プロジェクトのマネジャーは、ライター 
を集めるだけ集めて、そのパワーを最大限に活かすことができる。たとえば、1つのモジュール 
に取り組む時間 （2 〜3時間）しか持っていないライターには、1つのモジュールだけを割りあて、 
仕事が遅れているライターの分は、他のライターに回したりすることが可能になるのである。 

“執筆者”は、自分に割りあてられたモジュールのうち、どれから書き始めてもよい。1つの 
モジュールの穴埋め作業が遅れたとしても、他のモジュールは独立して書くことができ、互い 
に影響をおよぼし合うことがないからである。 

GOTO なき設計の有効性は、初稿執筆のときばかりでなく、作成されたモジュールの見直し 
と編集の際にも、さらに如実に現われる。簡単にいえば、ストーリーボードの内容さえ分かっ 
ていれば、どのモジュールに対しても、見直しや編集作業を行なうのに不都合はない。さらに、 
設計を何ら変更しないと分かっていれば、ページ数や図の番号を、モジュールの書かれる順序 
に関係なく、前もって決定することができる。 

ライターが書くのは、長くて複雑に入り組んだ一連の節ではなく、小型の自己完結的なマ 
ニュアルの集合体である。この自己完結型モジュールは、技術面での記載事項に関しては、 
すでに点検済みである。またそのマニュアルのロジックに適合しているだけではなく、その 
マニュアルの「物理的な」書式にもフィットするものとなっている。したがって、 ライターの 
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図表 9.1 < GOTO なきマニュアルの有効性> 

仕事は、「何か を創造することではなく、既定の事柄を実行すること」 なのである。 

•構造化の手法の醍醐味は設計にある 

このように、構造化された方法で マニュアル 作成を行なうと、初稿を書き上げることのおも 
しろ味が薄れてしまう、という現象が起こってくる。本来なら、第一稿を書くことこそ、 マニュ 
アル 作成においてもっとも複雑かつ困難で、しかも興味のある部分なのだが、構造化された方 
法の場合には、もっともつまらない過程となってしまうのである。（知力とセンスを必要とする 
事柄は、ほとんど設計の段階に移されたことを思い出していただきたい。）もちろん、1人の人 
間が マニュアルを 書き上げる場合も、構造化された方法から得る利益に変わりはないが、プロ 
のライターは、おうおうにしてみずからの設計をただ実行するだけでは満足せず、わき道にそ 
れて、ところどころ自分の創意を入れたがる。 

したがって、設計は技術の専門家とマニュアル作成者（あるいは編集者）の2人に任せ、残り 
の仕事は、この2人が割りあてた者に遂行させるというのが、ベストの方法といえよう。 
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マニュアルへの 構造的 アプローチ 


9.2 “執筆者”を選択管理する 


構造化されたマニュアル作成においては、初稿を書くことは、ストーリーボードの設計通り 
に細部を書いていくことにすぎない0だが、従来のマニュアル作成方法では、初稿の執筆こそ 
が、マニュアルの内容を組織化し、提示する試みなのである。この違いが、“書く”ということ 
に対する従来の考え方を変更するよう迫る。 


•従来のマニュアル作成には互換性がない 

マニュアル作成をプログラミングになぞらえるのは、必然的でもあり教訓的でもある。構造 
化分析と構造化設計の手法を用いていないプログラマーは、漠然とした直観的な“スペック” 
にたよって、ソース•プログラムを組んでしまう。プロのテクニカルライターでも、マニュア 
ル作成において、同様の誤りを犯すことが少なくない。 

従来の構造化されていないマニュアル作成において、第一稿はひとかたまりの全体である。 
せいぜい2、3の大まかなブロックに分かれていればましな方である。したがって、第一稿の作 
成は、ただ1人のライターの仕事となるか、せいぜいごく少数のライターの共同作業となるにす 
ぎない。こうしたマニュアル作成では、アウトラインのスペック（仕様書）などないに等しい 
から、マニュアルの各部分をうまく結び合わせるという複雑な作業が、どうしても1人の人間に 
任されてしまう。外側からマニュアルをコントロールできないため、マニュアルの各部分のっ 
じつまが合うようにするのは、内側からのコントロール、つまり1人のライターの頭の中で、と 
いうことにならざるを得ない。 

このような方法では、マニュアルがいくっかの大きなブロック（それぞれが独立したマニュ 
アルといってもいいようなもの）に分かれていない限り、チームワークは不可能に近い。作業 
を小さく分けてしまうと、各部分が互いにうまく適合することは望めなくなってしまう。この 
問題は、構造化設計の手法が導入される以前のプログラミングにっきまとっていた“互換性の 
ない コーディング •スタイル”の問題に似ている。 

•モジュールの数だけライターを集める 

これと対照的に、各 モジュールの スペックが すべて そろっていて、しかも どのモジュール も 
小型で独立したものであり、さらに、それぞれのスペックに技術的な内容に関する重要な記述 
がきちんとなされていれば、初稿の作成もまったく異なった様相を帯びてくる。さらに、各モ 
ジュールの 並び方が 、 GOTO なきロジックにたがわぬものであり、 マニュアルの 設計が 「凍結 
されて」いれば、初稿の執筆は、通常“書く”という言葉から連想されるものとは似ても似っ 
かないものになる。 

この場合の“マニュアル作成”は、何人かの“執筆者”が、テキストや図表のまだ記述され 
ていない細部を埋めていく作業から始められる。ただし、「1回の作業の対象となるのは、1っの 
モジュールだけ」である。したがって理論的には、モジュールの数と同じ数のライターが、そ 
れぞれ独立して作業することができる。少なくとも理論上は、どんなに長いマニュアルであろ 
うと、必要な数の“執筆者”がそろっていて、ストーリーボードが完成していれば2〜3時間の 
間に初稿を書き上げることもできるのである！ 

1人か2人の執筆者しか見っからない場合でも、マニュアル作成をモジュール化することの利 
点は大きい。マニュアル全体をいくっかの小単位に分割して、モジュール相互の関連性（“イン 
ターフェイス”）には気を遺わず、どのような順に書いてもよいことになるからである。 
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•書きたがらない人に書かせる 

構造化の手法の大きな利点は、「書く」ことがいやでいやでたまらない人でも、ライターとし 
てどんどん起用できる点にある。こうしたやり方をする場合、執筆者として起用するのは、モ 
ジュールの細部の細部に至るまでよく知っている人である。執筆者の役割は、前もって指定さ 
れた場所に、詳しい内容を正しく書き込んでい〈ことである。それらの内容は、関係者によっ 
てすでに設計され、点検、承認されたものである。このようにお膳立てされ、しかも“文章力 
は問題でない”といわれても、なお書こうとしないプログラマーやエンジニアがいたとしたら、 
彼または彼女は、どんな条件下でも、たぶん書こうとはしないだろう。 

このような、 およそ執筆者のタイプでないような人を、執筆者として起用することによって、 
マニュアル 作成の ス ピー ドが上がるだけではなく、その技術的内容がより正確なものになる。 

書くのは苦手だが、専門知識は誰よりも確かであるという人に書かせると、ぎこちない文体で 
あっても、正確さが増すのである。これはプロのライターにとっても都合がよい。なぜならラ 
イターは、初稿の修正と手直しに専念できるようになるからである。 


モジュール番号 

締 切 

担当執筆者 

1..0 

5^^ 10/1 

Brown 

2.0 

S ^ TO 1〇/1 

Brown 

P .1 

1〇/1 

Brown 

2.2 

10/] 

Brown 

2.2.1 

10/5 

Lopez * 


10/5 

Blum * 

2.3 

10/1 

Gilles 

2.3.1 

B^TO 10/3 

Gilles 

2.3 .P 

5^^ 10/3 

Gilles 

2.4 

10/1 

Wright * 

2.5 

10/1 

Finch 

3.0 

10/1 

Jones 

3.1 

10/1 

Jones 

3.2 

10/1 

Jones 

3.3 

10/5 

Calder * 

4.0 

10/1 

Finch 

4.1 

S^TO 10/1 

Finch 

4.1.1 

10/5 

Finch 

4.1.8 

5 分货 10/5 

Wamier * 

4.1.3 

IQ /5 

Jackson * 

4.2 

10/15 

Archive 

4.3 

10/15 

Archive 

4.4 

10/15 

Archive 


図表 9.2 く執筆者にモジュールを割りあてる〉 
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マニュアルへの 構造的 アプローチ 


9.3 執筆者の管理にプロジェクト•マネジメントを応用する 


マニュアルをたった1人のライターが書き上げる場合でさえ、ストーリーボードの作成やモ 
ジュール化による設計手法は大きな助けになる。さらにそのメリットは、プロジェクトの規模 
が大きくなり、チームのメンバーが増えるにつれて飛躍的に大きくなる。構造化の手法を用い 
ると、「執筆作業の管理面」に劇的な変化がもたらされる。まず第一に、執筆作業の全段階を通 
じて、力配分が均一化され、第二に、プロジェクト•マネジメントのテクニックを、そっくり 
そのままマニュアル作成に応用できるということである。 


•従来のマニュアル作成ではプロジェクト管理ができない 

マニュアル 作成を構造化することにより、初稿を執筆.編纂するやり方が根本的に変わり、 
マニュアル 作成者は、いわば マネジャー （管理者） の 役割を果たすようになる。 

少なくとも2人以上のライターを必要とする規模のマニュアルなら、そのうち誰か1人が、全 
体を統括する責任者とならねばならない。しかし、この責任者として プロ グラマーの1人に白羽 
の矢を立てたとしても、また、マニュアル作成の管理の プロを 連れてきたとしても、従来のマ 
ニュアル作成の体制では、まともな管理などできるはずがない。従来のアウトラインをもとに 
仕事を進める限り、マニュアル作成にかかる時間と コストをコントロール することは、ほとん 
ど不可能であり、品質管理にも限りがある。 

図表 9.3 a は、従来の方法と構造化の方法を比較したものである。従来のやり方では、アウト 
ラインの作成とプランニングに少し時間をかけた後、仕事量の低迷期が長く続く。この間、プ 
ログラマーやライターは、たいてい守備範囲とサイズのはっきり決まっていない執筆の分担を 
割りあてられ、呻吟に呻吟を重ね、ついに締切りを迎え（あるいはオーバーし） てし まう。責 
任者側では、やきもきしながら初稿が上がってくるのを待っているが、予定通りできてくるこ 
とはめったにない。 

したがって、責任者自身が、ほとんどの部分を大急ぎで書き上げざるを得ない はめに なり、 
編集と見直しのための時間など、望むべくもなくなってしまう。 

•構造化の手法ではコストやスケジュールを管理できる 

従来型の マニュアル作成とは対照的に、構造化されたマニュアル作成においては、プラン 
仕事量 



企画 アウトライン 初稿 締切り 


マニュアル作成過程 

図表 9.3 a <従来型のマニュアルと構造化マニュアルの作成過程における仕事量の対比〉 
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ニンダと設計に時間がかけられる。その代わり、アウトラインが完成していれば、数時間の間 
にモジュール（すべて小型で独立している）の第一稿を責任者のもとに集めることができる。 
したがって、編集、テスト、訂正などに要する時間をも含め、全過程を通じて、作業の力配分 
が「均一化」されるわけである。 

予定通りに割りあてのモジュールを書き上げることのできない執筆者がいれば、責任者はた 
だちにその原因を調べ、必要ならば、時間的余裕のあるうちに、他の執筆者を割りあてること 
ができる。 

このように、マニュアル作成を分担作業にし、そうした作業のネットワーク全体を通して細 
かい調整を行なっていくと、構造化の方法のもう1つのメリットが見えてくる。各モジュールは、 
はっきりと定義された1つの作業単位であるため、プロジェクトのネットワークの中に正確に位 
置付けることができるというメリットである。各モジュールは、仕事量のはっきりした1つの作 
業であり、担当者、推定所要時間はもとより、場合によっては、アートワーク（レイアウト、 
デザインなど）や製作（版下製作、印刷、製本など）にかかる費用もはっきりしている。管理 
者は、コストを前もって見積り、モジュールの割りあてをやりくりすることにより、完成時期 
を予想し、調整することができる。万事がうま〈いった場合、モジュールはすべて相互に独立 
しているため、作業工程を制約するのは、1人の執筆者に複数のモジュールが割りあてられてい 
る場合だけになる。 

モジュール 化の手法を徹底すればするほど、予算を守り、作成プランの“クリティカルパス*” 

を短縮することができる。 さらにライターを管理する側(素人であれプロであれ）にとって、 
現在、小型コンピュータで可能となっている新しいプロジェクト•マネジメント•ツールを利 
用するチャンスも出てくる。 



図表 9.3 b <マニュアル作成作業のネットワーク〉 


訳注*クリティカルパス ： Critical Path 。 プロジェクト•マネジメントの用語で、スケジュールに遅れが出る 
と、プロジェクト全体に影響を与える一連の作業の筋道。個々の作業の所要日数と優先順位を分析す 
ると、プロジェクトを順調に運ぶためにどうしても遅延させることのできないひと連らなりの作業の 
筋道が、少なくとも1本はあることが分かる。並行して行なえる作業を増やすことによって、このク 
リティカルパスを短縮することができる。 
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マニュアルへの 構造的 アプローチ 


10.1 初稿をテストする：中心課題 


初稿をテストする目的は、表現上の誤りを“取り除く”ことである。読者のミスを誘発する 
ような文章、あるいは難解で曖昧なために、読み直さなくてはならないような文章などを、で 
きる限り何回も修正することである。 


•編集作業は言葉の見直しから 

“構造化されていない”マニュアルの初稿は、従来型のアウトラインや仕様書によって書か 
れているため、たいていの場合、かなり読みにくく、新しい技術的な内容がぎっしり詰まって 
いるのが通常である。したがって、技術面での見直しが早急に必要となる。そして時間が許せ 
ば、文体の見直しを行なって、さらに他の技術面での見直しをすばやく行なうことになるだろ 
う。一方、構造化されたマニュアルにおいては、モジュールごとの見直しが可能である。構造 
化されたマニュアルの技術的な内容は、すでにチェックを受けているため、言葉と体裁をまず 
整え、それから細部に記載漏れがないかどうかについて、技術面での見直しを簡単に行なうだ 
けでよい。 

構造化されていないマニュアルの初稿は、前もって責任者からチヱックやテストをまったく 
受けていないため、ほぼ90%が新しい内容に関する記述となる。このような初稿に対しては、 
技術面で正確かどうか、細かいところをチェックする作業から始めるしかない。ところが、初 
稿が編集されておらず、散文的なために、この見直し作業は難航する。したがって言葉や図表 
を整え、読みやすくし、より効果的なものにするといった作業を行なう機会は、事実上なくなっ 
てしまう。 

これとは反対に、構造化されたマニュアルの各モジュールは、それ自体で小型の自己完結型 
マニュアルとして機能する。モジュールの技術的な内容と、モジュール間の論理的なつながり 


図表 10.1 <初稿テストの2つの方法〉 


構造イ匕されていな L 、初稿の場合 

構造化された草稿の場合 

第一稿全体について 

各モジュールごとに 

「まずは技術白勺な見直しから」 

• 複雑なテキストを初めて読む 
•主な誤りを見つける 

•技術的誤りを、混乱した、曖昧な言葉遣い 
の中から識別 

「まずは言葉の見直しから」 

• 手の加えられていない原稿の言葉の見直し 
• 曖昧な内容を明確にする 
• 欠陥と矛盾を見極める 

「言葉の見直しは駆け足で」 

•ケアレスミスのぞんざいな見直し 

• 些細な編集見直し 
• 印刷と製作のための仕様書を書く 

「1回目の技術的な見直し」 

• ストーリーボード上でまだテストされていない 

技術的内容の確認 

• 最後になされた技術的変更との祭合性を見る 

「最後は技術的な見直し」 

• あわただしい、形式的な二重チェック 
• 役に立たない更新(間違いだらけのページ） 

「最後は言葉の見直し」 

• 言葉と図表の有用性をさらに向上させる 
• 製作、校正を注意深く行なう 
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は、あらかじめ技術面の専門家によって明確に定められており、また、他の専門家によってチ 
ヱツクを受けているのである。モジュール内の記述が技術的に見て突飛であることはなく、ま 
た、見直し作業が最後まで引き延ばされることがないため、言葉や技巧の面での見直しから開 
始することが賢明である。技術面での誤りを見つけるには、初稿に対してよりも、整理された 
(編集された）文章に対しての方が容易である。 

言葉の見直しは、テキストの「明快さ」（曖昧な情報や誤解を招くような情報が取り除かれて 
いるかどうか）、「読みやすさ」（必要以上に難解ではないか、特に対象読者にとって読みづらく 
ないかどうか）、といったことを目標に行なわれる。一般的には、初稿の編集に努力を傾注すれ 
ばするほど、意味が一層はっきりし、読みやすくなる。 

たとえプロのライターによって書かれた原稿であっても、 マニュアルを 使いやすくするため 
には、初稿に対して例外なく編集作業を行なわなければならない。 

籲見直しの5つの観点 

編集作業を行なう場合、通常以下の5っのカテゴリーにおいて見直しが行なわれる。 

•機械的作業：文法上のミス、誤字 •脱字、 不正確な区読点を訂正する。これは意味の混 
乱を正す基本的な作業である。 

• 適切な言葉に直す作業：読者になじみの薄い言葉を使って必要以上に難しくなっている 
文章、調子の悪い言い回しなどを修正する。 

• 意味をはっきりさせる作業：複数の意味に解釈される、あるいは読者の誤解を招くよう 
な単語、文節、文章、構文、図表を修正する。 

•読者のなじみやすさを高める作業：たどたどしい、あるいはくどい表現、難解な図表な 
ど“必要以上に飾りたてて”、結局は読者にとって使いにく くなってしまうようなものを 
修正する。読者がもう一度文頭に戻らなければ意味がはっきりしない文章など、初稿に 
は必ずといっていいほど存在する言い回しを修正する。 

•読者を引き付ける作業：言葉遣いに注意し、緻密な編集を行ない、文の長さに工夫をこ 
らし、巧みな作図を行なうなどの作業を通して、マニュアルに対する読者の興味を高め、 
魅力的な内容にする。 

もし、会社の誰かが編集に費やされる時間にクレームを付けたとしたら、こういうといい。 
「意味の明らかでない文は、技術的なミスを覆い隠し、トラブルを招く」と。たとえば次のよう 
な文はどうか。 

「管理陣には、プロジェクトの継続を承認するために、書式 A 51 にサインすることが求めら 
れる。」 

この文はとんでもない混乱を招く。この文のもっとも悪い点は、管理陣が、ある書式へのサ 
インを要請されているとも、あるいは強制されているとも解釈できることである。これらの解 
釈は、本来の意味とは異なる。後述する原理にあてはめるなら、以下の通り改めるべきであろ 
1 〇 

「管理陣は、プロジェクトの継続を望むならば、書式 A 51 にサインしなければならない。」 
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マニュアルへの 構造的 アプローチ 


10.2単語や言い回しのバグを取る 


もっとも簡単な編集作業は、よく使われる単語や句のバグを取り除いたり訂正したりするこ 
とである。特に、長たらしい言葉や流行の言葉で飾りたてられた表現、必要以上に言葉を使っ 
ている表現、逆に言葉を省略しすぎた表現、語や句を間違った場所に置いている表現、などに 
は注意が必要である。 


言い回しの上でよく犯されるミスの中には、二重の弊害をもたらすものがある。第一はテキ 
ストの中の技術的な内容の誤りや脱落を隠蔽してしまうことである。第二は、読者がテキスト 
を読み返したり読み違えたりする可能性を増やしてしまうことである。 

•表現の凝りすぎ 

日常的な短い言葉で充分なのに、次のような持って回った表現で文章を飾ることがある。 

「使う （use)」 の代わりに「〜を利用する （utilize)」 

「助ける （help)」 の代わりに「助成する （facilitate)」 

「開始 (start) 」の代わりに「創始 （initiation) 」 

「押す (press) 」の代わりに「押し下げる （depress) 」 

誤解しないで欲しい。短い単語を使うこと_体に意味があるわけではない。また、技術的に 
正しい言葉を、不正確な短い言葉に直してもメリットはない。しかし、次のような言い換えに 

も何らメリットはない。 

「示す (show) 」の代わりに「指し示す （indicate) 」 

「送る （send)」 の代わりに「普及させる （disseminate)」 

「させる （cause)」 の代わりに「引き起こす (effectuate)」 

文章を飾りたてる方法として、次のような流行語(仲間内の専門用語）を使う場合もある。 

「能力 （ability)」 の代わりに「可能出力 (capability)」 

「ランク付けする （rank)」 の代わりに「優先順位を付ける (prioritize)J 

また「環境 (environment)」 という言葉は、あまりにも頻繁に、そしてあまりに不注意に用いら 
れ ている ため、同じ マニュアルの 中でも、反対の意味に使われて いる ことさえある。さらに、 
透過的 (transparent) という言葉にも注意して欲しい。この言葉は、商業英語では“明白な” 
という意味だが、 コンピュータ 業界では“目に見えない”という意味になる。 

籲言葉の使いすぎ 

必要以上に多くの単語を使うことは、300ワード（日本語で700字）で説明できる考えを、1000 
ワード（日本語で2500字）に増やすという出来の悪い学生の方法である。以下に若干の例を掲 
げる。 

•〜というケースに合致すると立証できるならば=もし〜なら （should it prove to be the case that = if) 

•〜の使用を行なうという意味によって =~ で (by means of the utilisation of = with) 

•〜をする時間の早い時点において = そのとき （at the ealier point in time = then) 

•見積りの算出を行なう = 見積る (perform the calculation of the projection = project) 

初稿では表現がどうしても冗漫になる。冗漫な表現でもっとも目につくのは、 

〇動詞の名詞化：（「区別する （distinguish)」 の代わりに「区別を行なう (make a distinc¬ 
tion) 「〜を結合する （link)」 の代わりに「〜間の結合を実行する (accomplish linkage 
Detween ノ」） 

〇単純な表現の複雑化：（「〜のために （to)」 の代わりに「〜を目的として （in order to)」、 
「〜について （about)」 の代わりに「〜という事柄に視点を向けると （with regard to the 
subject of )」） 

という 2 つである。また場合によっては、句の代わりに節を用いることで表現が冗漫になる。 
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たとえば、 I テスト計画を承認して、われわれは〜を始めた （Having approved the test plan , 
we began the ...)」 の代わりに「われわれはテスト計画を承認した後に、われわれは〜を始め 
た （After we had approved the test plan , we began the … ） 」といった具合である。 

修省略のしすぎ 

必要以上の言葉の省略が、エンジニアやプログラマーの文章によく見うけられる。ライター 
にも、簡潔さを求めるあまり、次のように理解不能になるまで句や節を縮める者がいる。 

「このシステムには“自然言語型報告書作成機能”がある (English-like report generating capability) J 
隣接セクター.リファレンス•デジグネイター (contiguous sector reference designators)」 

「操作可能言惟潇定用資料書式 15ft 基準 （operational planning materials format design criteria) J 
「管理責任分担ヒストリー.ファイル （management resposibility assignment history file〉」 

このような名詞の結び付き方（プログラマーなら「名詞結合形態」というだろうが）につい 
て理解できる人はまずいない。ちょっとやそっとの修正を加えても、役には立たないだろう。 

上述のようにわけの分からない方法で前置詞を省略する者や、単語のすし詰めを作る者は、 
「その （ the )」 とか「ある （ a )」 といった“無用な”言葉を削除したがる。また、「上述の （ that )」 
といわずにすむ場合は、彼らはそれを省略してしまう。そればかりか、必要でない句点 （ comma ) 
はできるだけ省略したがる。こうした極端な省略指向や削除指向は、言葉の流れを破壊し、確 
かに短い表現ではあるが、解読するのは長くなるという文章を作り出してしまう。 

籲語順の間違い 

単語や語句を置く位置を間違えることも、意味の流れをとぎれさせてしまう。英語では、修 
飾語は被修飾語と並べて（一般的には、直前に）置かれるべきである。しかし、初稿ではおう 
おうにして、修飾語の多くが置かれるべき所に置かれていない。特に、「唯一 ( only )」、 「およそ 
( nearly )」、 「ほとんど （ almost )」、 「すでに （ already )」、 「〜でさえ （ even )」、 「ちょうど ( just )」、 
といった言葉は、間違った場所に置かれることが多い。 

「唯一■、一般労働条件外の貝に時給制度を導入せよ」 （only enter the hourly rate for exempt employees.) 

この文の「唯一 （ only )」 は、何にかかっているのだろうか。「時給制度のみ （Only the hourly 
rate )」 という意味か、「時給のみの制度 （the hourly rate and nothing else ) J という意味か、 
あるいは「一般労働条件外の従業員のみ （the hourly rate only for exempt employees .)」 だろ 
うか。 

「このシステムは、ほとんどすべての人々のチェックをプリントします」 （The system prints nearly everyone’s 
checks.) 

といいたいときに、 

「このシステムは、すべての人々のチェックを、ほとんど （nearly) プリントします」 

(The system nearly prints everyone’s checks.) 

と書いてはならない。 

同様に、修飾部と被修飾部が遠くなってもならない。なぜなら、 

「企業方針に抵触するので、すべての合法アクセスを報告しなさい」 

(Report every unauthorized access in keeping with company policy?) 


という文では、 

「ある非合法アクセスが企業方針に抵触するものでなかったら、報告しなくてもよい」 

(ii the unauthorized access is not in keeping with company policy, you snould not report it) 

という解釈も可能となるからである。 
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マニュアルへの 構造的 アプローチ 


10.3文章のバグを取る 


文章をダメにする要素は星の数ほど存在するが、それらが読者を立ち往生させたり、注意力 
を散漫にしたりする場合、おおむね次の5つの欠陥が原因となっている。つまり、読返しを強 
いるような文章構造、つながりのよく分からない述語、主語の分かりにくい受動態、宙ぶらり 
んの導入部、牛のよだれ文がそれである。 


•強調したい部分は文末に 

文書を読みやすくする秘訣は、その文章で執筆者が“強調したい事柄”（強調したい事柄があ 

る場合）を最後に持ってくることである。 これ以上論理的な方法があるだろうか。文章が長い 

場合、その文章は頭から順々に読まれ、理解されていく。したがって、文章の最後の部分が、 

記憶にもっとも鮮明に残るのである。もし、どんな重要な事柄でも、文頭に置かれるなら、読 

者は文章を読み終えてから、最初に戻って“繰り返し”読まなければならないだろう。 

素人のライターでも、練習さえすれば覚えられることだが、初稿をチェックする際に、強調 

されるべき事柄が文末にきているかどうか調べ、もし強調される事柄が文末になければ、文章 

を作り直し、強調部分を文末に持ってくることができる。ただし、技術的な理由から強調部を 

文末に持ってこられない場合は、この限りではない。では、この変換練習を始めてみよう。 

変換前「コスト低下は、新しい作業手順の最大持質である。」 

(Reduced cost is the main advantage of tms new procedure.) 

変換後「新しい作業手順の最大の特質は、コスト低下である。」 

(The main advantage of this new procedure is reduced cost.) 

同様に、命令文の編集を行なう際は、キーワードを最後に置けばよいのである。また、条件 
付きの指示文 ( if - then ) では、「指示の部分 （ then )」 を最後に持ってくるべきである。次に「良 
い例」と「悪い例」を挙げる。 

[悪い例] DFIL が入力される。 （DFIL is typed.) 

[良い例]入力すべきは DFIL である。 (Type DFIL.) 

[悪い例] DFIL と入力すると、ファイル名がチェックできる。 

(Type DFIL to see what tile names have been assigned 」 

[良い例]登録されているファイル名をチェックする場合は、 DFIL と入力せよ。 

(To see what file names have been assigned, type Dr iL.) 

•述部をお払い箱にするな 

強調部が文末にくると、文章の中の“動作部分”は、たいてい「述部」にきて、主部にはほ 
とんどこない。しかし、多くのライターは、強調部を文頭に持ってくるばかりでなく、関心を 
ひく事柄を、すべて動詞を使う前にいってしまうことさえある。後に残るのは「つながりのよ 
く分からない述部」である（エディターの中にはこれを“お払い箱の”述部と呼ぶ者もいる）。 

「日本人によるダンピング（標準価格以下の値をつける-^安く見積る）の可能性が存在して 
いる」という文を考えてみよう。この文の述部は“存在している”という部分である。しかし 
この文を組み換えてみるとライターがわれわれに理解させようとしたことが、おのずと分かる。 
(1) 日本人が ダンピング する恐れがあるのは、 われわれ である。 (The japanese may underprice us.) 

(2 ) われわれがダンピングされる恐れがあるのは、日本人によってである。 （We may be underpriced by the japanese.) 

(1) も （2) も文法的に正しい文だが、 （1) は「われわれ」を強調しており、 （2) は「日本人」 
を強調している。 

•受動態の良い例悪い例 

言語には、文頭から文末への言葉の置換えを可能とする多くの方法がある。「置換え方法」の 
中でも、もっとも使いやすいのが受動態である。次に例を見よう。 
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( 1 ) ZAKO 社が買収したのは、 XTRON である。 （ZAKO Industries acquired an XTRON.) 

(2) XTRON が買収された相手は、 ZAKO 社である 0 (An XTRON was acquired by ZAKO Industries.) 


このように能動態から受動態に換えることで、強調される言葉も変わってくる。 

一方、多くの編集者やライター養成者は、素人のライターに対して、受動態に注意するよう 
警告している。これにはそれなりの意味がある。受動態にしたばかりに、せっかく分かりやす 
かった文脈を破壊し、かえってもつれさせてしまうこともある。以下にその例を見よう。 

[受動態]柔軟性の乏しさか露呈されるのは、このシステムによってである。 

(Insufticient flexibility is exhioited by the system.) 

力態]このシステムは、あまリに柔軟性に乏しい。 (The system is too inflexible.) 

[受動態]安価な照合作業と結合作業が実現されるのは、このデバイスによってである。 

(Cheap collating and binding are accomplished by this device.) 

[貪 _ 態]このデバイスは照合作業と結合作業を安価に行なう。 (This device collates and binds cheaply.) 

受動態では表現がくどくなり、分かりにく くなる。しかし受動態は、扱いさえ気を付ければ、 
もっとも“強調したい事柄”をもっとも効果の発揮できる位置（つまり文末）に持ってくるこ 
とができる。 

•導入部と主部の主語に注意 

また、主要な部分を文末に置くもう1つの方法として、「導入部」を利用する方法がある（ほ 
とんどの条件付き指示文が導入部を持っている）。この方法の危険なところは、導入部が宙ぶら 
りんになるという点である。つまり、単語の意味が文の主部と切り離されてしまうのである。 

これを克服することも難しいことではない。導入部を文法上の主語と結びつけ、主語を句点 
の直後に置くのである。以下に良い例と悪い例を掲げる。 

[悪い例]あなたか賀金台帳を簡単にまとめたいとお望みなら、 PAAY はあなた向けのシステムです。 

(With your simple payroll requirements, PAAY is the system for you.) 

[良い例]あなたか賃金台帳を簡単にまとめたいとお望みなら、「あなた」は PAAY システムを使うべきです。 

(With your simple payroll requirements, you should use the PAAY system j 
[ 悪い例]コマンドの意味をすばやく見るために、用語一覧はワークステーションごとに置かれています。 

(To locate definitions quickly, glossaries are posted at each work station.) 

[良い例]コマンドの意味をすばやく見るために、「オペレーター」はワークステーションごとに置かれた用語一覧を利用 
することかて•きます。 

(To locate definitions quickly, operators can use the glossaries posted at each work station.) 
[悪い例]コールドスタートでシステムを立ち上げるときは、 0S テープが口ー ドされます。 

(When coldstarting the system, the operating system tape is loaded.) 

[良い例] コール ドスタートでシステムを立ち上げるときは、（「あなた」は） 0S テープを口ードしてください。 

(When coldstarting the system, {you) load the operating system tape) 

參牛のよだれ文は禁物 

ほかにも、文末で意味のつながりが切れてしまうこともある。“プリンターの保守作業禁止は 
喫煙時”©〇 not service the printers while somokihg ) といったバカ気た表現には、注意し 
て欲しい。（この文は“煙の出ている間はプリンターの保守作業禁止”とも読める） 

最後に、肝に命じておかなければならないのは、文章というものは「牛のよだれ」のようにだらだら 
と続けるべきものではないということだ。たとえば、次のような文書は手の付けようがない。 

実線用、破線用、ぼかし用、センターライン用、不可視ライン用フォントに加えて、さまざまなボイント数の活字セットが 
発売され、可変スペーシング(幅）、挿入オプションのレイヤー、右寄せ、左寄せ、センタリング付きでセンターライン用の新 
製品となりました 。 (In addition to solid, dashed phantom, centerline, and invisible line fonts, numerous 
linestring fonts are available that provide generation about a centerline with variable spacing(width). layer 
of insertion options, and left, right, and center justifications.) 


訳注：このモジュール内の訳文は、日本語としてやや不自然な語順になっているが、それは英文の[良い例] 
と[悪い例]を際立たせるためである。念のために。 
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10.4指示文を曖昧にする10項目 


単語、文節、文章のバグは、どれも例外なく「正確さ」と「有用性」を引き下げる。したがつ 
て曖昧な指示文に対しては、高い代償が支払われることになる。 


1 . 流行語指向で遠回しな表現になっている 

[ 編集前 ] インフォメーション • センター環境において、マネジャーは、優先化ランキングの方法を活用して、均等分割スケジューリングを 
助長する のとする〇 (In tne Information Center environment, the manager should utilize a prioritization ranking 
to facilitate equitable scheduling.) 

[ 編集後 ] インフォメーション • センターで、マネジャーは、すべての仕事に優先順位を付け、公正なスケジュールを作る。 

(In the Information Center, the manager ranks each job to yield a fair schedule.) 

2. 必要以上の言葉が使われている。 

[ 編集前 ] 書込みの許可が与えられているのはどのファイルかを識別するための知識に不足があるという事態に陥った場合、 PRIFIL コ 
マンドの使用を実 よ 。 （In the event that you have a lack of knowledge regarding which files you have 

permission to write in, make use of the PRIFIL command.) 

[ 編集後 ] どのファイルに書き込んでよいか分からなければ、 PRIFIL コマンドを使え。 

(If you do not know which files you may write m, use the PRIFIL command.) 

3. 必要以上に言葉が省略されている 

[ 編集前 ] カラム • ヘディング修正許可は、 HCOL の入力で得られる。 

(し olumn heading revision permission may be obtained by HCOL entry.) 

[ 編集後 ] カラムのへディングを変える許可を得るには、 HCOL と入力せよ。 

(To get permission to change the headings of the columns, enter HCOL.) 

4. 単語や文節が間違った位置に置かれている 

[ 編集前 ] ワーク . シートには、変更ではなく、修正を書くだけにする。 

(Only write corrections, not changes, on the worksheet.) 

[ 編集後 ] ワークシートには、変更ではなく、修正だけを書け 。 （On the worksheet, write only corrections, not changes.) 

5 . 文頭に戻らなければ文意がはっきりとしない表現がある 

[ 織前 ] 「Clear Rest 」 キーを押すときは、力ーソルの後ろにあるものすベてを消去するときである。 

(Press the Clear Rest key if you want to erase everything after the cursor.) 

[ 編集後 ] 力ーソルの後ろにあるものすべてを消去したいときは 、 「Clear Rest 」 キーを押せ 0 

(If you want to erase everything atter the cursor, press the Clear Rest key.) 

6. 意味のはっきりしない述部がある 

[ 編集前 ] キーパンチング開始前のコーディング • シートに対するスポット • チェックの有効性は、特質に値する。 

(The efficiency of spot-checking the coding sheets before commencing keypunching is worthy of mention.) 
[ 編集後 ] 有効的なことは、キーパンチングを始める前にコーディング • シートをスポット • チェックすることである。 

(It is efficient to spot-check the coding sheets before you start to keypunch.) 

7. 意味のはっきりしない受動態がある 

[ 編集前 ] 注意が払われなければならないのは、機密情報の送信である 。 (Care must be exercised in sending sensitive data.) 

[ 編集後 ] 機密情報の送信には注意せよ 。 （Send sensitive data carefully.) 

8. 関係のはっきりしない表現がある 

[ 編集前 ] 貸借勘定が一致したら、仕訳伝票ファイルは } 東結されなければならない。 

(When reconciling the account, the encumbrance file must be frozen.) 

[ 編集後 ] 貸借勘定が一致したら（あなたは） fJ: 訳ファイルを凍結せよ。 

(When reconciling the account, (you must) freeze the encumbrance file.) 

9. 関係ない人物が登場する 

[ 編集前 ] オペレーターはその時点で自分の暗証コ _ ドを人力する 。 (The operator then enters his or her security status.) 

[ 編集後 ] あなたの暗証コ _ ドを入力せよ 。 (Enter your security status.) 

10 •“義務付けを曖昧にする表現”がある 

[ 編集前 ] オペレーターはデータを入力する前に、 40 時間の指導を受けることが 1 つの要請である。 

(It is a requirement that operators receive 40 hours of instruction before they enter any real data.) 

[ 編集後 ] オペレーターはデータを入力する前に、 40 時間の指導を受けなくてはならない。 

(Operators must receive 40 hours of instruction...) 
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図表 10.4 a く編集前の記述〉 

1. あなたのハードウヱア構成が充分な RAM 容量を有するならば、あなたはシステムの ウィン ドウ機能 
を活用できる。 

(If your connguration has sufncient RAM capacity, you may utilize the system’s windowing 
capability.) 

2. 予測に対する評価を留保する場合をはっきりさせるならば、あなたには、これに代わるディスカウント 
レートを使用することについて選択権がある。 

(Should it prove to be the case that you have some reservations regarding the forecasts, you 
have the option of using alternative discount rates.) 

3. 早い時期のマニュアル設計は、構成上の有用性の利益を生む。 

(Early manual design yields procedural usability benefits.) 

4. スライド•メーカーが唯一利用され得るのは、 512K 装備のシステムおよびハード ディ スタとともにであ 
る。 

(The slide-maker only can be used by system with 512K memory and hard disKs.) 

5. PINSTALL と入力するのは、印刷のオプションを変えるときである。 

(Type PINSTALL to change the printing options.) 

6. 最低 10 分間に 1 回データをセーブするという必要性を満たすためには、あなたの注意がなくてはならな 
ない 0 

(The urgent need to save data at least every ten minutes is called to your attention.) 

7. ファイル結合は、キー指定によって実現される。 

(File linkage can be accomplished by key specification.) 

8. 計算機能を呼び出すには、 <alt> とく c> が押されなければならない。 

(To call the Calculater, <alt> and <c> must be pressed.) 

9. 事務員は、この時点で目的のファイル番号を人力すべきである。 

(The clerk should then type the number of the desired file.) 

10. 前の当番の 人からのト ラブル報告書を読む ことは、 交替した オペレーターの 責務で ある。 

(It is tne responsibility of arriving operator to read the trouble report irom the latest shift.) 


図表 10.4 b 〈編集後の記述〉 _ 

1. あなたのコンピュータに充分なメモリーがあるなら、ウィンドウ機能を利用することができる。 
(If your computer has enough memory, you can use the window feature.) 

2. 予測を疑うのなら、他のディスカウント • レートを試すことができる。 

(If you doubt the forecasts, you may try other discount rates.) 

3. 早い時期からマニュアルを執筆すると、使いやすい構成になる。 

(Writing manuals early makes the procedures easier to use.) 

4. スライド.メーカーは 512K 装備のシステム、あるいはハードディスクがないと利用できない。 
(The slide-maker can be used only by systems with 512K memory or hard disk.) 

5. 印刷のオプションを変えるには、 PINSTALL と人力せよ。 

(To change the printing options, type PINSTALL.) 

6. 最低 10 分間に 1 回は、データをセーブせよ。 

(You must save the data at least every ten minutes.) 

7. ファイルを結合するには、キーを指定せよ。 

(To link the files, specify the keys.) 

8. 計算機能を呼び出すには、（あなたは）く alt> とく c> を押せ。 

(To call the Calculator, (you) press <alt> and <c>.) 

9. 目的のファイル番号を入力せよ。 

(Type the number of the file you want.) 

10. 交替したオペレーターは、前の当番の人からのトラブル報告書を読まなくてはならない。 

(The arriving operator must read the trouble report from the latest shift.) 






154 


マニュアルへの構造的アプローチ 


10.5読みやすさのために編集する 


I 可読性（文書の読みやすさ）」という言葉は、個々の文書の難解性と反対のことを指す。「難 
解性」という言葉は本書では文章を読み取るのに必要なあらゆる努力を示す。可読性を表わす 
多くの指標の中でもっとも一般的なのは、簡単な方法で文章の難解性を表わす指数を就学年数 
(学年）とほぼ一致させる 、 Robert Gunning 氏の「フォグ指数」と 、 Rudolph Flesch 氏の 
「読取り尺度」である。 


今日では、「可読性」を測定するための多くの指数や尺度がある。最近では、 5 つの尺度で可 
読性を測る Bell Labs 氏の“ライターのワークベンチ”がある。 

可読性の尺度と呼ばれるものは、どれも大ざっぱである。中にはでっち上げではないかと思 
われるものもある。その尺度では“読みやすい”と判定されるように巧みに作られた文章が、 
実際には、ほとんど読むに耐えないものであることを誰もが経験しているだろう。しかし、こ 
れらの尺度の目的は、読者が文意を読み取るときの難易度を、“客観的に”評価するところにあ 
る。もっとも一般的な尺度は、読解が困難になるにしたがって、数«：が上昇する。そして、こ 
の数値と“読解に必要な就学年数（学年）”とが等しくなるように工夫されている。 

もっとも有名なのは 、 Robert Gunning 氏の「フォグ指数」である。この指数は、1つのセン 
テンスの中の平均単語数に、“難しい”単語のパーセンテージを加え、就学年数と読解の難しさ 
が一致するように、この和に定数 0.4 をかけるという方法を取っている（“難しい単語”とは3 
音節以上の単語である。ただし、固有名詞、簡単な単語の複合語、3音節であっても r - ed 」 か 
r - es 」 で終わる単語は、数えない。） 

では、フォグ指数をテストするために、以下のテキストを見てみよう。このテキストは、世 
界最大級のソフトウヱアやハードウヱア会社によって作成されたものである。 

Today’s advancements in educational management combined with the rapid growth in 
student enrollment in schools has emphasized the need for data processors to be used in 
establishing and maintaining a student records data base , required for providing 
attendance and academic mark reporting data to satisfy several disciplines . The purpose 
of this program product is to provide a systematic procedure for recording , retrieving , 
manipulating , and reporting significant student data , such as attendance and academic 
mark information . One of the objectives of this program is to provide effective data on 
individual students as well as aggregate , statistical reports needed for sound analytical 
decisions by educators and administrators . 

この文章には、センテンスが 3 つ、単語が 105、 Gunning 氏のいうところの“難しい”単語が 
34個 ある。したがって、フォグ指数は、 0.4 X (35 + 32) =26.8 となる。 

これは、就学年数が 26 年以上ないと、たやすく上記の文章を読むことができない、というこ 
とを表わす。これでは、この文章を簡単に読める人は、地球上にはいないことになる！しかし、 
文章の内容は、ほとんどないに等しく、少し修正を加えれば、フォグ指数は10〜11に低下する 
のだから、この文章の作成者にとって、まったく気の毒な結果としかいいようがない。 

(米陸軍は、軍内で使用しているマニュアルの難易度を調べるのにもう1つ別の尺度を採用 
している。それは 、 Rudolph Flesch 氏の「読取り尺度」を軍自身が改良したものである。この 
改訂版 Flesch 尺度を上の文書にあてはめてみると、やはり結果が就学年数と一致するよう工夫 
されている。） 

もちろん、このような文章の可読性の指数が低ければ、問題のすべてが解決されるわけでは 
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ない。レベルが6〜7 (年）では、知性に訴えるような表現ができないという場合もあり得よ 
う。また、このような簡単な指数に対して、あるいは単純に可読性を測定するということ自体 
に対して、異論を唱える人もいよう。しかし問題は、非常に難解な文章から意味を読み取るこ 
とは、大部分の読者にとって不可能であるという否定できない事実である。しかも、バグが排 
除されたマニュアル、間違いのないマニュアル、 GOTO を排除するように正しく企画•設計さ 
れたマニュアルであっても、依然マニュアルが読みにくいという問題を抱えている場合がある 
のである。 

したがって、以下の基準を採用することが有用である。 

技術書はすべてフォグ指数が14を超えてはならない。ビジネス文書は、すべて同12を超えて 
はならない。事務員向けマニュアルは、すべて同8を超えてはならない。技術書が簡単であれ 
ばあるほと、多くの人々にとって読みやすいものとなるのである。 

図表 10.5 <可読性の 2 つの測定方法> 


フオグ指数 （ Gunning ) : 

読解に 必要な 就学 年数 = 0.4 X ( センテンス あたり の 平均単語数十難しい単語* のパーセンテージ） 
* 難しい単語=3音節以上の単語。ただし以下のものを除く。 

• 固有名詞 
• 短い中.語の段合語 

• 3音節目が- ed あるいは - es の単語 


Flesch 読取り尺度 （ 米陸軍による改訂版） 

読解に必要な就学年数=〔0 . 39 X ( 平均単語数/センテンス） + 11.8 X ( 平均音節数/単語)〕_15 . 59 
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10.6実証：フォグ指数で文章を編集する 


初稿に対する編集の効果を明らかにするため、現在使用されている2つのマニュアルからテ 
キストを引用し、実際に“編集前”と"編集後”の文章を示す。編集後の2つの文章は、いく 
つかの点で改善されているが、特筆すべきは、フォグ指数の測定値が示す通り、読む上での難 
解性が大きく緩和されていることである0 


次に掲げる文章は、実際に使用されているマニュアルの一部であり、大手国際金融会社がプ 
ロジェクトを推進していく上で利用しているガイドラインである。 


編集前： 

Following identification of needs and appropriate preliminary approvaloi all major 
system development project proposals , the Information Systems Department will prepare 
an analysis and recommendation for action . The more routine requests will be approved 
by concurrence of the Information Systems Department and of the financial area 
management without further review . Those requiring a change in policy , exceeding the 
approved budgets or crossing organizational lines will require review and approval by 
the Steering Committee as well . 

The Information Systems Department will evaluate the capability of the user or 
regional technical staff to implement a proposed system . Based on this evaluation , the 
responsibilities and authorities of the Information Systems Department , regional te ¬ 
chnical staff , and the user will be outlined in a system development proposal submitted 
to the Steering Committee . 


単語：127、センテンス文： 5、“難しい”単語： 37、フォグ指数： 21.6 

少し手を加えれば、こうした必要以上に難しい（しかしよくあるタイプの）文章もいちだん 
と読みやすくなり、業務管理上の手続きも、プロジェクトの担当者にとって実行しやすいもの 
となる。 

編集後： 

rirst , needs are identified and major development proposals get preliminary approval . 
Then , the Information Systems Department analyzes each request and recommends as 
action . 

For small , routine requests the Information Systems Department and the manager of 
the functional area may approve the project without further review . (A project is 
“ routine ” if it does not call for a change in policy , exceed current budgets , or cross 
organization lines .) 

For major requests , though , the Steering Committee must also approve . To advise 
them , the Information System Department submits its own evaluation , which proposes 
schedules and tasks for all the participants . 


単語： 97、センテンス： 6、“難しい”単語：12、フォグ指数：11.4 
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次の“編集前”の例として、 FORTRAN のプログラム•ガイドを掲げる。これは、大手の time 
-sharing company によって作成されたものである。 

編集前： 

It is critical that variables used as subscripts in FORTRAN programs always be 
consistent with information declared in the DIMENSION statements . Unless checking is 
specifically requested , subscript ranges are not checked for validity when programs are 
run . This checking is omitted in order to maximize running-time efficiency . However , if 
invalid values are used for subscript variables , such as a value less than one or greater 
than the maximum subscript as specified in the DIMENSION statement , errors can 
occur . Often such errors either go undetected or cause apparently unrelated failures and 
diagnostics . 

When invoking the FORTRAN compiler , the user can inform the compiler that 
subscripts are to be checked for range validity by supplying the SUBCHK option . 

単語：115、センテンス： 6、“難しい”単語： 21、フォグ指数： 14.8 

この“編集前”の文章は、2〜3回読み直さないと理解できない。1回だけで理解できるプ 
ログラマーは、この内容について、すでに知っている者である。一方、“編集後”の文章は、特 
定の誰かを対象として“程度”を下げることもなく、一般の人々の大半に内容を正しく伝えて 
いる。一般の人々も以下に掲げる文章の方を選ぶであろう。 

編集後： 

Variables used as subscripts in FORTRAN programs must stay within the range of 
those in the DIMENSION statements . (That is , the value of the variable must not be less 
than 1 or greater than the highest subscript in the DIMENSION statement .) If they are 
out of the range , invalid , the mistake is often overlooked . Worse , these errors often cause 
“ unrelated ” failures or odd diagnostic messages . 

To save running time , this system does not check the range of the variables unless told 
to . To be safe , when you invoke the FORTRAN compiler , tell it to validate the values 
with the SUBCHK option . 


単語：100、センテンス： 6、“難しい”単語： 8、フォグ指数： 9.8 


158 


マニュアルへの 構造的 アプローチ 


10.7マニュアルの吸弓 I 力を高めるその他の方法 


読者を引き付けるマニュアルを作成するためには、マニュアル作成者は、読者の気をそらす 
原因をできる限り取り除き、マニュアルの中身を信頼できる形で提供し、加えて効果的なペー 
ジのレイアウトを考えなければならない。 


•読者の気をそらす原因 

マニュアルおよび情報製品は、「読者の注意を引き付けるもの」でなければならない。読者の 
気を散らせる原因は、ほとんどがうっかりミスや製作上のミスである。誤字•脱字、おかしな 
位置の区読点、文法上のミス、用語の不適合、頭字語や略語の説明不足、へたくそなレイアウ 
卜、ぼけた写真や色分解、などがそうである。これらのバグは、その存在自体は他愛のないも 
ののように思えるかもしれないが、インストラクションの効力を薄れさせ、読者の集中力を散 
漫にするには充分である。さらに、これらのバグが頻繁に登場し、バグがあることがあたりま 
えということになると、これはもう不注意でだらしがないと思われても仕方がない。つまり何 
のことはない、読者に最悪のメッセージを送っているのと同じことになるのである。 

こうした意味からも、すべてを読者からできるだけ「信頼感を引き出せる」ような形で行な 
うことが重要である。小さなバグにも注意を払って編集作業を行なうのもいいだろう。印刷や 
製本において高品質を確保するのもいいだろう。マニュアルに高価な紙を使用すべきか否かを 
問うのは、もっとも難しい。しかし高価な紙を使えば、安手の紙を使用するよりも、ユーザー 
の反応がよくなることは間違いない。 

•“バーゲン品”は高くつく 

マニュアルの 印刷がプリンターで行なわれるのなら一つまり人間ではなく機械でという意味 
だがーインクが裏まで“にじみ出ない”ように、充分厚い紙を使用する必要がある。機械は“バー 
ゲン品”であっても、 マニュアルの 出来上がりが“安物”であってはならない。 

安くつくと思えるもの、またそれ自体が安くみえるものは、すべてマニュアルの有用性を低 
下させる恐れがあることに注意して欲しい。これらはたいてい、マニュアルに対する読者の信 
頼感を損ねるものなのである。真剣に作られなかったマニュアルは、読者も真剣に読もうとは 
しない。したがって、安価な材料や方法でマニュアルを作成すると、多くの場合、読者をほと 
んど寄せ付けないものとなってしまう。たとえば、1ページにできるだけいっぱい文字を詰め 
込もうとする、大きな活字を使わない、太字を使わない、“レタリング”を入れない、その他、 
高くつく書体はいっさい使わない、といったような方法で作られたマニュアルは、読者にとっ 
て苦痛でしかない。 

籲紙の節約は努力の節約 

さらに、マニュアル作成者は、紙の節約を第一義と考えるようなマネジャーには、警戒の念 
を抱かなければならない。紙を節約しても、コミュニケーションが効率よく行なえるわけでは 
ない。余白を大きく取り、大きな字で印刷する方が、読者にとっては都合がよい。それもすベ 
ての読者にとってである。きちんと整理されたページ構成は、読み疲れしにくく、したがって 
読み間違いも少なくなる。「厚い紙を使う」「装丁を丈夫にする」「章の切れ目にタブを入れる」 
「読みやすい書体や色を選ぶ」といったことは、本質的ではないにしろ、システムからその本来 
の有用性を引き出す助けとなるのである。 

マニュアル 作成者はまた、無理な言葉の省略、頻繁な略字の使用、その他の短縮形によって 
マニュアルのページ 数を節約しようとするような札付きの編集者にも警戒しなくてはならな 




編集：読みやすさ、明確さのためにテストと見直しをする 


159 


い。同じ意味の言葉について、一方に明快で簡潔な書き方があり、もう一方に短縮されて意味 
の通りにくい書き方があるが、これらの間には大きな違いがある（この文章の中で、「一方に」 
と「もう一方に」という言葉を削除しようとする編集者は、私のいいたいポイントを理解して 
いない )0 

籲編集の専門家を雇え 

最後にいいたいことは、大量のマニュアルを作成している企業や組織は、.有能な専門職の編 
集者を抱えるべきだということである。プログラマーも教育次第では、少しはましな文章が書 
けるかもしれない。ワープロは、文法上のミスやスペルのミスはチェックしてくれるし、フォ 
グ指数の計算もやろうとすればできる。しかし、「内容をうまく伝えるためには、忍耐と繰返し 
が必要である」ということを理解している人、「簡潔性と密集性の違い、緊密性と乱雑性の違い」 
が分かる人が、必ず誰か必要である。そして、「マニュアルの作成作業の諸要素を“ランク付け 
する”ことがいかに恐ろしいか」を知っている人がたぶん必要となるだろう。 

図表 10.7 <用紙の節約対可読性（読みやすさ）の向上> 


用紙を節約する場合 

ユーザーの 便宜を考える場合 

狹ぃ余白 

広い余白 

小さな活字、ぎっしり詰まったレイアウト 

大きな 活字、 さまざまな書体サイズ 

イラスト、図表を最低限に抑える 

大きな図表、イラストを頻繁に使用 

セクションごとの改ページがない 

セクシヨンごとに改ページ 

繰返しの回避、最低限の説明 

redundancy 、 読者を引き付ける工夫 

タイプ打ちの表題や図表 

正式な活字印刷による表題、本格的な図表 
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マニュアルへの 構造的 アプローチ 


11.1 マニュアルを保守する：刺激と反応 


どんな マニュアル も、完成後の変更が必要になるだろう。事実、どの企業を見ても、ごく最 
近作られたものを含め、あらゆる文書に変更の必要性があるというのが世の習いではないだろ 
うか。この変更という作業段階で、もっとも考慮すべき重要な課題は、文書およびその補遺を 
供給する際に、いかにうまく全体を管理するかということである 0 マニュアルの 変更や改訂の 
衝動を1つの刺激とみなし、それに正しい反応を返せるようつかさどるルールをメンテナンス基 
準、あるいはメンテナンス•ポリシーと考えよう。 


プログラムやシステムと同様、マニュアルなどのまとまった文書を確実に保守（メンテナン 
ス）するにあたって、まず最初にやらなければならないことは、保守の職務にあたる人を選ぶ 
ことである。誰かが責任を持たなければ、おそらくその職務は遂行されないだろう。どの書類 
についても、担当者が誰で、それが正しく供給されているか否か、またその書類の更新や補足 
が適切な時期になされ、適切な人に送られているか否か、ということを管理しなくてはならな 



図表 11.1 < 刺激と反応> 

•メンテナンスを促す刺激 

あらゆるマニュアルは、変更が必要になるだろう。図表11.1に示すように、いかに注意深く 
見直しかなわれても、マニュアルは次のような刺激に応えなければならない。 

• 技術的なミスーシステムやソフトに関する不正確な、あるいは不完全な技術的情報。 

• 技術的な変更ーマニュアルの作成中にシステムに加えられるごく小さな修正。 

マニュアル作成者に知らされる場合もあるし、知らされない場合もある。 

•表現上のミスー曖昧な、不明確な、あるいは誤解を招くようなテキストや図表、文法上の 
または誤字*脱字などのケアレスミスも含む。 

• システムのバージョンアップーソフトやシステムになされる大きな変更または“新機能の 
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追加”。予定されている場合もあるし、そうでない特別な場合もある。 

•方針変更一何をなすべきか、何をなし得るか、担当を誰にするかに関する新しいルール。 

繰り返していうが、誰かが責任を持って、これらの問題を見失わないようにして、必要な努 
力を怠らないようにしなければならない。しかし、誤解してもらっては困るが、いくら責任が 
あるとはいえ、つねに新情報の報告、通達、発表を際限なく繰り返す必要はない。 

いずれにしろ、忘れてはならないもっとも重要なことがある。つまり、 マニュアル 作成者が、 
マニュアルを色の あせない、間違いのないものにしたいと 思う 気持ちはよく分かるが、どんな 
マニュアルも、どのみち時の流れには勝てないということである。 「マニュアルを いかに手っ取 
り早く更新あるいは言丁正できるか」ということが問題なのではない。問題は「どの変更をしば 
らく保留にしておけるか一つまり“一括更新にできるか”一そしてどれを直ちに伝えなくてはな 
らないか。一括にしたもののうち、どれを2、3日、あるいは2、3週間、あるいは数ヶ月保留で 
きるのか」ということである。 

參刺激に対する4つの反応 

実際には、刺激に対して、次の4通りの応え方がある。 

• 内部的更新 

マニュアルのマスターバージョンを修正することである。つまり、保守責任者のファイル 
に保管されている内容を変更することである。このファイルには、マニュアルの修正済み 
個所、修正の必要な個所、および出版スケジュールが書き込まれている。この内部ファイ 
ルにあるものは、すべて最優先事項であり、できる限り最新の状態が維持されている必要 
がある。 

• 即時更新 

ューザーやマニュアルの所有者全員に緊急報告を送ること。当然これは重要な伝達事項の 
ために取っておかなくてはならない方策である。というのは、突然緊急報告が送られると 
混乱をきたし、またシステムが混沌とした状態に陥ったか、あるいは“狼が来た！”の類 
だろう、という印象を与えてしまうからである。 

• “一括”更新 

いくつかの変更事項をひとまとめにしたもの。定期的（月1度、3ヶ月に1度）、あるいは 
変更の量がある基準線を超えた場合に出される。 

• 改訂版作成 

究極の更新である。この場合でも、定期的にまたは変更の量に従って、マニュアル作成者 
は、前回の編集以後の修正を、すべて新しいマニュアルに組み込む。つまり古くなったも 
のを取り除き、修正されたものに置き換える。こうしてユーザーや DP センターは、改訂版 
を受け取る。（古いものを返してから改訂版を受け取るのが理想である。） 

つまり、反応の仕方はいく通りかあり、緊急の度合いもいく通りかある（あらゆる工学技術の 
問題がそうであるように）。それでも、熱心なマニュアル作成者は、その熱意のあまり、ひっき 
りなしに改訂を行ない、明確さよりむしろ混乱を招いてしまうこともよくある。 
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マニュアルへの 構造的 アプローチ 


11.2 見越しの設計でメンテナンスを改善する 


マニュアルその他の文書をメンテナンスしやすく、修正しやすいものにするためには、初め 
からこれらのことを考慮して設計しなくてはならない0モジュール化されたマニュアルで、し 
かもモデルの段階のうちにテストが行なわれているものであるならば、その後の変更の必要性 
が少なくなるばかりでなく、何らかの変更が必要である場合でも、その変更を実行したり管理 
したりするプロセスは単純なものですむ。 


•メンテナンスは設計段階から 

ソフ トウエア • エンジニア リングの世界ではあたりまえのことになっているが、プログラム 
はその設計の初期の段階で、すでにメンテナンスの便宜を考えて作成される。プログラムが作 
成された後でもメンテナンスはできるが、設計段階 で考慮、 された場合ほどたやすくはいかない。 
システムを“後で組み直す”試みは、見上げたことではあるが、むしろ無謀というべきだろう。 
こうした試みは、なるべく初期の段階でなされるに限る。出来上がった後の組直しがうまくいっ 
たためしはほとんどない。 

メンテナンスのしやすさとは、システム内のバグや欠陥や不適当な部分をいかに簡単に、そ 
していかに手早く探し出し、明確にし、訂正できるかという総合的な目安である。 システムカヾ 
メンテナンスしやすいかどうかは、たいていの場合、システムのコスト効果を占う唯一最大の 

指標である。 

これと同様に、コンピュータ.システムに付随するマニュアルやその他の情報製品も、やは 
りメンテナンスされ修正されるべきものである。システムに変更か'*口わったり、バグが発生し 
たりすれば、それにともなってマニュアルも変更されなくてはならない。あるいは、マニュア 
ル自体が、システムとは関係ないバグや弱点を現わす場合もある。遅かれ早かれ、マニュアル 
をメンテナンスしたり修正したりすることは、マニュアルを書くことよりも高くつくというこ 
とが分かるはずだ0そして、メンテナンスしたくてもできないマニュアルは、おそらく失敗作 
ということになるだろうし、そのマニュアルによってサボートすべきシステムの使いやすさを 
大幅に引き下げる結果にもなる、ということも分かるだろう。 

•モジュールの登録簿を作る 

マニュアルをメンテナンスするもっとも簡単な方法は、第一に変更する必要のあるモジュー 
ルを見つけ出すこと、次にそれを訂正するか、あるいは別のものと置き換えることである。マ 
ニュアルを修正する場合でも、どのみち訂正や置換えの代わりに、モジュールを付け加えるべ 
き正しい位置を見つけ出し、それをそこに挿入するという作業をともなうこととなる。 

マニュアルがモジュール化され、構造化されていれば、すべてのモジュールの登録簿を保守 
(メンテナンス）することができる。その登録簿では、各モジュールに関し、該当するシステム、 
項目、適応業務、導入場所、その他関連する詳細な記述子などが、コード番号などで明記され 
る。このようにモジュールを登録簿で管理しておけば、システムに何らかの変更があった場合、 
それに影響を受けるすべてのモジュールを探し出すことができる。また、古いモジュールから 
新しい文書を作り出すことも可能なはずだ。 

マニュアルが、モジュールの組合わせによってのみ構成されるものであると考えるなら、登 
録簿は図表 11.2 a のように保守することができる。1つのモジュールが数ヶ所で用いられること 
は充分考えられるので、このような登録簿によって、システムの変更に影響される「すべて」 
のマニュアルの部分を知ることができる0 
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図表 11.2 a <モジュールの登録簿から> 


モジュール名 ：レコードの追加 モジュールファイル番号： B -008 

最初の30字： 

レコードを追加するには、ファイル名を GOTO win に入力する 


上位モジュール： B -008 

4つのファイル処理を利用する 

下位モジュール： B -028 

既存のレコードを追加する 

B -029 

キーデータなしでレコードを追加する 


詳細 

プログラム/システム： DB -3 不動産管理 システム、 貸付管理 システム 
適応業務： ファ イ ル 作成、 ファ イ ル 更新、新規勘定、 • 新規レコード 
対象：エンドューザー、不動産仲介業者、貸付管理者 
導入先： ABCO ファ イナンス、 Goldschmidt & Wong 不動産 
その他： 

当該 モジュールを 含む マニュアル/情報 製品： 

G -3、 G -4、 G -5、 F - l 、 F -2、 F -7、 R - l 、 R -5 


図表 11.2 b <出版したモジュールの登録簿> 


モジュール番号 

B -008 

B -028 

B -029 

C -110 

C -115 

C -240 


等価モジュール番号 

R - 006、 D -120 
R -061、 D -121 
R -062、 D -122 

R -090 

D -600 


マニュアル/情報 製品番号 

G -3、 G -4、 G -5、 F - l 、 F -2、 F -7、 R - l 、 R -5 

G -3、 G -4、 G - 5、 F -7、 R -5 

G -3、 G -4、 G -5、 F -7 

G -2、 G _ 3、 G -4、 G _ 5 

G -4、 G -5、 R _ 5 

G -3、 G -4、 G -5、 F -7、 R -4、 R -5 


•メンテナンスを見越してマニュアルをデザインする 

大規模な先進企業では、“等価モジュール”といわれるような、同じ技術的内容を持つ、交換 
可能なバージョンを取り入れているところもある。図表 11.2 b に示す登録簿を見れば、マニュア 
ル作成者は、技術的な变更がなわれた結果、どのマニュアルを変更しなければならないかを 
一目で見ることができる。もちろん、この図はどちらかといえば複雑で大がかりである。もっ 
と簡単な見越しの設計を選べば（つまり、マニュアルを前もってメンテナンスしやすい設計に 
すれば）、それによってマニュアルはもっとメンテナンスしやすくなる。たとえば、ルーズリー 
フのバイン ダーに 収められたマニュアルは、当然製本されたものよりも変更しやすい。（しかし 
逆に、ある種の間違った情報は、あえてルーズリーフを用いないことによって、未然に防ぐこ 
とができる場合もある。） 

1ページず つの、 つまり用紙の片面にだけ印刷したモジュールは、もっとも簡単に追加や削除 
や挿入ができる。したがって、絶えず変更の必要があるマニュアル用のモジュールとしては、 
おそらく最良の形式であろう。しかし一方、1ページモジュールにすると、一貫性のない、複雑 
な参照や繰返しの多いマニュアルになりやすい。1ページモジュール—本文と図表が同じページ 
にあるもの一はメンテナンスという点では優れているとしても、2ページモジュールの長所であ 
る信頼性と可読性（文書の読みやすさ）には代えがたいものである。 
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マニュアルへの構造的アプローチ 


11.3 メンテナンスのパラドクス：やりすぎは逆効果 


マニュアルの メンテナンスは、よほど注意深い方針を立てて行なわないと、補遺、速報、リ 
リース版、最新版などの配給がいい加減になったり、でたらめになったりしてしまう。多くの 
人が気付いていないことだが、 マニュアルに 付加情報を加えるたびに、違うバージヨンの マニュ 
アルが、実際世にあふれてしまうのである。そして、これらのバージヨンの中でも、正しいの 
はたった1つしかない、ということになつてしまう0 


争情報伝達の熱力学的法則 

またしてもあたりまえのことだが、時の流れに逆らえるマニュアルはなく、マニュアルには 
間違いが付きものである。もっと明確な、あるいは絶対に否定し得ないという言い方をすれば、 
複雑なプログラムやデバイスには、複数のバグが一確認されていないものも含めて一例外なく 
存在しているのである。 

もう1つあたりまえのことをいおう。ユーザー•リスト、配布先リスト、配布経路リストにも 
例外なく誤りがある。そして、リストが長くなればなるほど、ずさんなものになり、時の流れ 
に対応できなくなる。つまり、あるマニュアルの読者（あるいはシステムのユーザー）に、变 
更やその要点を伝えようと思っても、上記のリストがずさんで不正確であれば、その試みは挫 
折するのである。もちろん例外もある。プログラマー、オペレーター、ユーザーの3者が同一 * 人 
物の場合である。しかし、このような場合、どのみち正式な基準にのっとったマニュアルであ 
ることはまれである。 

上記の2つのあたりまえのこと、つまりどんなマニュアルも完璧ではなく、どんな配布先リス 
卜も完璧ではないということは、もはや技術的な情報伝達における自然法則である。これに、 
熱力学の第二法則* (エントロピーの法則）を加えるならば、なぜマニュアルの更新と修正にあ 
まりにも多くの挫折があるのか理解できよう。 

どんな変更が必要かを知り、その報告をまとめるという不断の努力も必要である。補遺や最 
新版の配給対象となる人々と、その宛先を確認するという気の遠くなるような努力も必要であ 
る。しかし、恐ろしいのは、何か得体の知れない手に負えない巨大な力が働いていて、そうし 
た努力をくじき、ねじ曲げようとしていることである。郵送システムには、官民を問わず、間 
違いが付きものである。たとえ電子メールやファクシミリを使っても、誤りはなくならない。 
また、受取人が配布された付加情報を、誤った場所に置く、誤った用途に使う、誤った解釈を 
する、さもなくば濫用するといったこともある。たとえば、付加情報が必要であるにもかかわ 
らず、まだ追加されていない マニュアルが、 いったいどれだけ読者の手もとに眠っているのだ 
ろうか。 

•バージヨンアツプは旧バージヨンを増やす 

マニュアルに 情報を追加することは一たとえそれが時流に対しても信頼性に対しても色あせ 
ない マニュアルを 作ることが目的でなされたにせよ 一 違うバージョ ンのマニュアルを、 世に氾 
濫させる結果になりかねない（つまり、入手した人とそうでない人の2種類の読者を産む恐れが 
ある）。 マニュアルの オリジナルが発行されたときは、1種類のバージョンしかない（もちろん、 
勤勉なユーザーによって抄出され、まとめられた非公式のバージョンは勘定外である）。しかし、 
マニュアルに 情報が追加されるたびに、 マニュアルの バージョンは、ねずみ算式に増えていく 
ことになる。 

つまり、補遺を2回発行すると、使用されるバージョンは4種類になり、4回発行すると16種類 
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になる。10回も発行すれば1キロバージョン （1024) にものぼる！ 

話をおもしろくしようとして、こんな説明をしているわけではない。かなりの人数のオペレー 
夕—や ユーザーに 対して、訂正版や更新版を送ったことのある人なら分かるだろうが、使い方 
のミス、設置場所のミス、管理のミスなど、起こり得ることは、事実起きているのである。 

差し出す側が、間違った内容を提出することがなくなったとしても、受け取る側が、それを 
間違いなく運用するとは限らない。旧バージョンに取って代わるべきものが、机の中にちゃん 
と入っているのに、旧バージョンが、相変わらず用いられている場合もある。 

籲情報の氾濫を防ぐ4つの方法 

誤った情報のたれ流しを完全にくい止める方法はないが、以下のような事柄を実施すれば、 
事態の改善につながる。 

•補遺の発行回数を制限し、それらをひとまとめにして蓄えておくと、マニュアルの配布経 
路に生じるノイズを低減できる。また、正規のスケジュールにしたがって、その補遺のま 
とまりを放出すると、もう1つの切実な問題を解決するのにも役立つ。つまり、必要な追加 
情報は「すべて」受け取っている、という信頼感を読者に与えることができる。マニュア 
ルの更新が不定期に行なわれるなら、ユーザーが受け取るべき情報に漏れはないという確 
信を持つことはあり得ないだろう。 

• マニュアルに書かれるべき内容を、できるだけ多くシステムそれ自身の中に組み入れてし 
まう。これによって、“印刷物”というどんどん古くなっていくものの量を減らし、問題の 
発生を抑えることができる。 

•更新を行なう際、情報源を単一の公認されたものに限定するのも効果的だろう。 

•補遺が発送される前に、書かれた内容を技術面の専門家に点検してもらい、認可してもら 
う。これによって、更新や訂正の回数を減らすことができる。特に、訂正の訂正という事 
態を避けることができるだろう。 


訳注*熱力学の第二法則：「エネルギーは秩序から無秩序へ、使用可能なものから使用不可能なものへという、 
1つの方向にのみ不可逆的に変化する」。たとえば、角砂糖をコーヒーに入れると溶けるが、溶けた砂 
糖はコーヒーと分離して再び角砂糖には戻らない(不可逆性)。そして溶けた砂糖は、角砂糖のときよ 
りも エントロピーが 増大している。つまり、 エネルギーは、 つねに エントロピーを 増大させる方向に 
のみ変化する。本書では、いったん流通経路に乗せた マニュアルを、 すべて回収して誤りを訂正する 
ことはできない、という意味と思われる。 
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マニュアルへの構造的アブローチ 


11.4 古し、マニュアルを“モジュール化’’できるか 


ゼロから始まるマニュアルはほとんどない0古いマニュアルを混ぜ合わせるか、更新するの 
が普通である。まれに古いマニュアルが“構造化された形式”に書き直される場合もあるが、 
このようなやり方は、うわべだけの整形手術になりがちだ0新規に作られてテストされたモ 
ジュール化マニュアルの利点を、本当に備えているものではない0 


•事後のモジュール化は可能か 

新規採用されたマニュアル作成者の任務の多くは、あまり評判のよくないマニュアルを手直 
しして仕上げる、更新する、グレードアップする、改訂する、さもなくば“整理整頓する”と 
いうものである。彼らが仕事を始めるように頼まれるのは、前章までに説明してきたようなマ 
ニュアル設計に関する決定が、ほとんどなされてしまった後なのだ。 

既存のマニュアルに関してはどうか。古いマニュアルを編集、あるいは改訂する仕事を請け 
負わされた作成者は、構造化の方法を利用することができるだろうか。手の付けられない、信 
頼性の低いマニュアルが、それ以上使いやすくなるだろうか。 

おそらくそれは可能である 。 Hughes Aircraft の編集者たちは、初めてモジュール化の方法 
( STOP * テクニック）を公表したとき、古い文書を新しい2 ページの フォーマット（形式）に作 
り蛮えることができた、と報告した。彼らの成功は、ある程度手掛けた文書の性格に負うとこ 
ろが大だった。つまりそれらの文書の多くは、すでに本文と図表が、均等にミックスされたも 
のだったからである。 

うってつけの マニュアルが 与えられれば、仕事のプロセスは、ほとんど遊びのようなものだ。 
まず、既存の マニュアルを1ページず つ切り離し、順番に並べて置く。そして、本文と図を吟味 
し、内容を モジュールの サイズに区切って印を付け、新しいヘディングあるいはヘッドライン 
を書き込み、必要ならごくまれだが、節や段落を組み換えたり、図を付録部分から本文に移動 



goto 11 
goto 20 
goto end 



step 1 
step 2 
step 3 




step 1 
step 2 
step 3 


図表 11.4 < 旧マニュアルを組み直す〉 
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させたりする。 

•モジュール化はラわべの整形手術ではない 

この考えがよいかどうかの判断を下すには、いくつかの要因を検討しなくてはならない。す 
でに述べたように、あるマニュアルが、他よりも構造化されたフォーマットに近ければ、それ 
だけ複雑な改訂作業を必要としなくなる。本文や図がよく書けているマニュアルは、残す（再 
利用する）だけの価値があり、その努力は報われる。しかし、マニュアルの多くは（古いプロ 
グラムと同様)、すでに時代遅れで役に立たなくなっている。これらを残そうとすることは、「新 
しいものを作り出すより、既存のものを再利用するほうが、時間と金の節約になる」というあ 
まりに通俗的な神話を認めてしまうにすぎない。 

繰り返すが、古いマニュアルの中には、ごく簡単に“モジュール化”できるものもある。そ 
もそも最初からストーリーボードなどなかった既存のマニュアルから、ストーリーボードを“ひ 
ねり出した”つわものさえいる。しかし多くの場合、古いマニュアルを作り直したり、組み直 
したりする方が、新しいものを作り出すより、もっとしんどい作業である。 

古い マニュアルの 物理的な構造や フォー マッ ト を、より読みやすい モジュール 化された 
フォーマットに 作り变えることが可能な場合でも、次のことは覚えておいて欲しい。 モジュー 
ル 化の方法は、 マニュアルの 内容に人目を引き付けるためだけの方法ではない。それは、ただ 
うわべだけの整形手術ではないのだ。 

モジュール化によるマニュアル設計は、その美顔術的意味合いはともかく、マニュアルのメ 
ンテナンスのしやすさや、修正のしやすさを確実にするための道でもある。すべて出来上がっ 
てしまった後（事後）にフォーマットを強制的にモジュール化しても、外見を良くすることに 
はなっても、校訂されてしまったマニュアルのメンテナンスのしやすさや信頼性は、たいして 
改善されはしないだろう。 

Yourdon と Constantine は、古いコンピュータ•プログラムの作り変えに関する討論で次の 
ように述べているが、私は彼らの意見に賛成したい。 

既存の プログラム や システムの 構造を、事後の モジュール 化を通じて大幅に単純化するのは、 
ほとんど不可能である。ひとたび コーディング（プログラミング） が行なわれてしまうと、 シ 
ステムの 構造の複雑さは本質的に定着してしまう。したがって明らかなのは、単純な構造にし 
たければ、最初からそれなりの方法で設計しなくてはならないということ だ 0 -Structured 
design (Englewood Cliffs , NJ : Prentice - Hall ), 1979, p .35 

その気があるなら、古いマニュアルを作り変え、組み直してみるとよい。しかし、最初から 
マニュアル作成を成功させるチャンスを逸してはならない。最初からモジュール化の方法でマ 
ニュアルを作るのと、そうでないのとでは有用性とコスト効果において、顕著な差が出てくる。 


原注* STOP : Sequential Thematic Organization of Publications の略。 1960 年代初頭に Hughes Aircraft 
corporation が開発した文書作成技法。 
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第12. 

本なきマニュアル 


12.1 マニュアル不要のシステムは可能か 

12.2 ユーザー•インフォメーションをオンライン化する 
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マニュアルの将来 


12. 1マニュアル不要のシステムは可能か 


確証はないが、印刷物としてのマニュアルは、そのべージ数が減っていく傾向にあるようだ。 
ユーザー向けの情報は、供給され利用される機会がどんどん増えているが、それは印刷物とい 
う形を取っていない0もっと重要なことは、オンライン•システムの特性が活かされているこ 
とである。オンライン•システムは、年々改良が施されるにつれ、それ以外の付随的なユーザー 
サポートをあまり必要としないようになってきている。 


•マニュアルは隅に追いやられる 

コンピュータ技術を利用している人々の大多数は書物を好まず、またそれをうまく活用しよ 
うともしない。こうした人々の数はさらに増え続けている。これらの人々の一方の極に位置す 
るのは、事務職員やデータ入力要員の一団で、彼らは能力もあり、才智に富んでいるが、分か 
りにくいマニュアルの中から自分の探しているものを見つけ出す術を知らない。またもう一方 
の極には、重役や管理職たちが位置する。彼らはあまりに多忙で、あるいは短気であるため、 

3節以上の文章を読む気はなく、誰かに質問してその答えを待つことに慣れてしまっている。 

マニュアル（特に百科事典的なもの） は、 邪魔な存在にもなり 得る。驚くべき ことに、ほん 
の2、3の部署しか本棚を備えておらず、マニュアルを開いて読める場所のある部署はもっと少 
ない。そこで、2冊のマニュアルを膝の上に バランス よく置いて システムに 向かう、というよう 
な人間工学を無視した事態が頻繁に発生することとなる。 

印刷物としてのその他の情報製品もまた、時流に取り残されずにいることの困難なものにく 
みする。“ ハードコピー” （これはふさわしいネーミングだが）は、ディスクやテープに収めら 
れた形で供給される情報などと違い、それほど容易に変更のきくしろものではない。したがっ 
て、印刷物としてのマニュアルは古くさく、時代遅れとなってもなおしぶとく存在して、使用 
され続ける可能性がある。 

従来の マニュアル にも、まだまだいくつかの利点がある一とりわけ、われわれのようにそれ 
らを再チェックしたり、編集したりする者にとっては一とはいうものの、ある種のシステムを 
導入する場合には、出版物としての マニュアルを 追い払う作業が当然必要となってくる。シス 
テムが マニュアルを まったく必要としなくなることはないが、資料をほとんど必要としないシ 
ステムはあり得るだろう。 

•マニュアルをなくす方法：その1 

出版物としてのマニュアルを排除するという目的を達成するためには、2つの一般的な戦略が 
ある。難しい方の戦略からいうと（結局はより効果的なのだが)、ューザーが最初のオリエンテー 
ションを受ければ、後はほとんど説明を受けずにすむようにシステムを設計することであり、 
またオペレーターやューザーがいっさい何も調べずにシステムを操作できるようにすること 
だ。この第一の作戦のキーポイントは、画面（特にプロンプト画面やメッセージ画面）を、平 
易な言葉でコミュニケーションが図れるよう工夫することだ 。 「INSERT FMTDSK 」 と表示 
するよりも「フォーマット•ディスクをインサートしてください」と表示した方が、マニュア 
ルの必要性は減少する。また、「チャートを作成する前に、フォーマットしたディスクを挿入し 
てください。」と表示した方が、マニュアルの必要性はさらに低くなる。（選択したチャートに 
は、フォーマットしたディスクのうちのどれがいいのかを示してくれる画面の方がもっとよい。 
ひとたび作業を開始したら、ューザーにどんなディスクも選択したり、見つけたり、インサー 
卜することを要求しないシステムが一層よい。）さらにいえば、ューザーが、フォーマット•ディ 
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スクの種類をリストアップした表を参照しなければならないなら、その表を画面上に表示させ 
ることで、一層マニュアルの必要性は減少する。 

なぜ何かを参照するという行為が必要かといえば、それは一般的にメッセージがコード化さ 
れたり、暗号化されたりしているからである。たとえば、「エラー17」というようなメッセージ 
は、「ライトエラーの項目参照」というメッセージよりサポートを必要とするが、後者もまた下 
記のメッセージより多くのサポートを必要とする。 

このファイル 内の レコー ドは変更できません。 

まずファイルの最初のレコードを確認してください。 

もちろん、もっとも効果的な方法は、システムをエラーが発生しても自動的に復帰できるよう 
なものにするか、エラーそのものが、起こらないようにすることである。 

エラーへの耐容力が強いシステムほど、マニュアルの必要性は低くなる。画面表示が乱雑で 
なく、略語や短縮語に頼らないシステムも同様に効果的だ。結局、システムを改良する最善の 
方法は、大量の説明を要する手順を、説明不要となるまで修正することだ。 

•マニュアルをなくす法：その2 

マニュアルの量を減らすもう1つの戦略は、言葉や図表を電気信号に変えることである。現今 
では、それはたいていシステム自身のディスプレイに表示されるものを意味する。表示される 
内容には、典型的なものとして2つのケースがある。1つは対話式教育用プログラム（通常ソフ 
トウヱア産業でいう“チュートリアル”）である。もう1つは「ヘルプ」機能（ューザーが必要 
となったときに、指導的なあるいは参照的な内容を表示する一連の画面）である。 

このチュートリアルやヘルプ画面には、何ら新しい内容は含まれていないことに注意して欲 
しい。チュートリアルとは、プログラミングされた教科書のようなものであり、ヘルフ。機能と 
は、内容検索のためのプログラムが付いた一種の参考書である。それらは決して目新しいもの 
ではないが、多くの場合、必要な対処策を行なうためのよりよい方法である。事実、チュート 
リアルやヘルプが適切にプロダラミングされているなら、それらは本書に述べられているすべ 
てのマニュアルの長所を備えているはずであり、マニュアルを利用しづらくしている回り道や 
枝分かれを完全に削除しているに違いない。換言すれば、うまく設計されたオンライン•マニュ 
アルは、文書化されたマニュアルをほとんど不必要なものにすることができる。 

文書化されたマニュアルにせざるを得ないものは、導入の手引とスタートアップ•ガイドで 
ある。すべてのマニュアルがシステム「内」にあるなら、システムの「外」にあるマニュアル 
のみが、システムの起動方法を教えてくれることになる。同様にいえば、プロンプト表示は、 
次の操作を指導するものであり、ヘルプ画面は、問題を解決するのに役立つものである。 

しかし、情報製品と情報サービスとの間に交換可能な関係があるように、文書化されたマニュ 
アルとオンライン化された情報製品の間にも交換可能な関係が成立する。そのどちらにも「本 
来的な」優位性はない。正しい分析、設計、テストが行なわれないと、オンライン•マニュア 
ルはもっとも複雑なマニュアルと同様、使いにくいものとなる。 
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マニュアルの将来 


12. 2ユーザー•インフォメーションをオンライン化する 


マニュアルに印刷されている内容はたいていの場合オンライン化できるが、はっきりさせる 
べきことは、単に端末のディスプレイにマニュアルの内容を載せ換えれば、使いやすくなるわ 
けではないということだ。 


•画面は一度に1つしか見られない 

マニュアルをオンライン化する上で忘れてはならないもっとも重要なことは、このマニュア 
ルのオンライン化という方法には、特に秘法があるわけではないということだ。パソコンが出 
現するまでは、文字を映像化するもっとも一般的な方法は、「マイクロフィルム」であった。し 
かし、マイクロフィルムを使わなければならない学生、研究者、あるいは資材部の責任者など 
のほとんど全員が、このシステムを不便で気乗りのしないものだと感じていることに注意して 
欲しい。 

新しい技術にはありがちなことだが、マニュアルをオンライン化する主な利点は、またその 
欠点でもある。従来のディスプレイ画面は、 25 X 80 文字というコンパクトなものであるため、 
ライターは情報を簡潔にまとめ、極小のモジュールに詰め込まなければならない。ューザーが 
一度にただ1つの画面しか見られないという事実がある以上（“ウィンドウ”については次に述 
ベる）、マニュアル作成者は、そこに表示させる内容をうまくまとめざるを得ない。よって、才 
ンラインによるューザーへの指示は、初心者、つまり限られた読解力しか持たない読者にとっ 
て理想的なものとなる。 

しかし一方では、画面がコンパクトであるがために、充分な説明や実演をするには、オンラ 
イン•モジュールでは、あまりにも小さすぎるという事態が起こってくる。2ページを一度に読 
むことが難しいのと同じように、2“ページ”分のオンライン画面を一度に読むこともほとんど 
不可能に近い。“ウィンドウ（画面上にボンと出てくる長方形の窓で、その中にテキストが表示 
される r を使ったとしても、たいした助けにはならない。1つのウィンドウ中に収まるものが、 
1つの画面の中に収まるものより多いということは決してない。それでは、1つの画面の中に3つ 
か4つのウインドウを開いたらどうか。これは、コンピュータ•シヨウでのデモンストレーシヨ 
ンをおもしろくするかもしれないが、たいてい分かりやすくなるよりも、混乱を引き起こすこ 
との方が多い。 

もちろん、これらの難点は、決して解消できないものではない。50列以上の文字表示ができ 
る“フルスクリーン”ビデオ•ディスプレイがすでに存在するし、また1つの画面上に複数のフ 
ルスクリーンを同時に映し出すことのできるウィンドウ.ソフトウエアもある。最終的にはこ 
うした技術がかなり一般的に普及するであろう。 

それまでは、オンライン•スクリーンが普通の本のページより小さくなるのは仕方のないこ 
とだろう。しかし将来、2ページ分の広がりで、3倍の量を乱雑にならずに詰め込むぐらいのこ 
とは可能になるだろう。とはいえ、ある1つの概念なり操作手順なりを一目で見ることができる、 
いわばテキストと図表のすべてを1ヶ所に収めることができるという点を過大視するならば、才 
ンライン.マニュアルはその適応範囲を限定してしまうことになるだろう0 
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図表 12.2 オンライン•インフォメーション（画面のフォトコピー） 

•オンライン.マニュアルにも設計が必要 

ほとんどの場合、オンライン•マニュアルは、次に何をしたらよいかを初心者に伝えるため 
のものである。それゆえに、マイクロプロ社のワードスター®のような洗練された製品では、 
ューザーが画面上の参照情報を一部分に限定したり、それを画面からすべて締め出したりする 
ことができるようになっている。図表12.2が示すように、もしもューザーがワードスター®の 
“ヘルプ”を最大限表示させようとしたら、画面が参照項目で埋めつくされ、文書はほとんど見 
えなくなるだろう。この製品のューザーのほとんどがコマンド用の参照カードを利用する理由 
はここにある。 

もっと性能のよいビデオスクリーンや新しいソフトウエアが登場すれば、これらすベての不 
平不満が、近視眼的なものだったということが分かるかもしれない。大型でもっと読みやすい 
ディスプレイは、不自由な状況を変えてくれるに違いない。その上、「サブ画面」がマニュアル 
のために使えるのなら大助かりである。特に、サブ画面が、画像や写真を鮮明に映し出すこと 
のできる高解像度ディスプレイ装置であるなら文句はない。 

しかしながら、技術がどれだけ進歩しても、マニュアル作成に関する課題は相変わらず残る 
だろう。なぜなら、スマートなタイプライターでくだらない文をタイプすることが可能なよう 
に、ヘルプメッセージに有害な情報を書き込むことも可能だからである。オンライン•マニ ュ 
アルは単なる「媒体」でしかなく、ューザーが要求し、必要とするものを伝達する方法でしか 
ない。ォンライン•マニュアルは、従来のマニュアル同様一いやそれ以上に一注意深く企画. 
設自十されなけれはならない。 
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マニュアルの将来 


13. あとがき：第五世代におけるマニュアル 


次世代のハードウェア（卓越した記憶機構とスピードを兼ね備えている）やソフトウェア（卓 
越した“知能”を持つ）は、従来のマニュアルの必要性を軽減するであろう。そしてゆくゆく 
は、現在マニュアル作成に費やされている技術が他の方向に向けられるだろう0つまり、主に 
アプリケーシヨンを開発したり、コンピュータと人間とのコミュニケーシヨンをより充実した 
ものにするという方向にである。同時に、この新しいテクノロジーは、並外れて優れたマニュ 
アルを「作成する」という方向にも使用されるようになるだろう。 


•第五世代はコミュニケーターが開発リーダー 

システムが使いやすいほど、そのマニュアルは書きやすい。システムの設計とそれを実現す 
る技術（ェンジニアリング）がすばらしければ、マニュアルにとっては、それだけで充分であ 
る。開発者がシステムに新しい特徴や機能（財務管理システムでのカラー選択、ステレオのイ 
コライザ ー、 電話のためのメモリーなど）を付け加えた場合のみ、ライターは創作意欲を呼び 
起こされる。 

このことは、大学がプロの マニュアル 作成者や テクニカル ライターの養成を始めてわずか2、 
3年しか経っていないのに、彼らの存在がすでに時代遅れになりかけている、ということを意味 
するのだろうか。もちろんそうではない。この新しい職業が、そんなに早く姿を消すことはな 

い 0 

そもそも、マニュアルライターという職業が衰退しても、そう簡単に彼らの仕事がなくなる 
ことはないだろう。 

しかしながら、コンピュータ•テクノロジーの最先端では、従来のマニュアルは間もなくあ 
まり必要とされなくなるだろう。システムはューザーにとってますます“意識しなくてよいも 
の”となるため、“人間との接点”は、ほとんど見られなくなるだろう。こうした状況下では、 
システムとューザーが意思の疎通を図る場合、コンピュータのプロンプトは分かりやすいし、 
コンピュータ自身がューザーの意思を推し測る能力を持っていることになるので、ューザーへ 
の“サポート”の必要性は、ますます軽減されるだろう。 

“サポート”、すなわちうわべはューザーがシステムから利益を得ることを助けるという意味 
だが、実はむしろューザーの方を知らず知らずのうちにシステムに適応させようとする念の 
入った表現であることの方が多い。システムの方がューザーに適応するようになったら、ライ 
ターは何をしたらよいのだろうか。 

それは明白だ。彼らはシステムの人間的かつ知的な部分を設計すればよい。それは、ブロン 
ブト表示やオンラインの参照画面を書く要領でできる。第五世代およびそれ以後も、プロのコ 
ミュニケーターの技能は、エレクトロニクスやソフトウェアのエンジニアの技能よりも、シス 
テムの成功にもっと欠かせないものとなるだろう。そればかりか、テクノロジーとその可能性 
についてもよく分かっているそうした有能なライターが、技術者の一団が通り過ぎた後の混乱 
を整理するという役に甘んじず、開発のリーダーになるかもしれない。 

•これからは“書吉手パワー”の時代 

また、第五世代のテクノロジーが、ライターやマニュアル作成者自身の上におよぼす効果に 
ついて考えてみるのもおもしろい。5年以上に渡って、私はクライアントに、どんな組織におい 
ても、書く作業をする人は直接ワープロを使って仕事をすべきだと提唱してきている。それは、 
何もタイピスト代を倹約するためではなく、それぞれのライターの表現力を高めるためである。 
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ペンやタイプライターからワープロに切り換えたほとんどの人が経験すること、特にプロのラ 
イターにとって、それはワープロによって自分の仕事の質が高められるということだ。ワープ 
口はあらゆる編集•校正作業を簡単にしてくれ、そのため、編集•校正作業はより活性化され 
る。すなわちそれは、頭に浮かぶ言葉と現実の紙との間の隔たりを縮めてくれ、カット•アン 
ド•ペースト（切貼り作業）を思うがままにさせてくれる。そればかりではない。通信機能と 
結び合わせれば、こうした新しいテクノロジーは、マニュアル作成のプロジェクトチームに 
“ネットワーク”を張り、最新の知識を交換し合い、お互いの書いて表現する能力を強化するこ 
とを可能にしてくれる。 

これからの時代は“書き手パワー”の時代だ。マニュアルの原著者あるいは責任者が、内容、 
ページレイアウト、グラフィック部分、印刷、配給をすべて管理できる時代である。また、文 
字や絵が無造作にデータベースから出入れされ、 コミ ュニケー ション •ネットワークの間を縦 
横無尽に飛び回る時代である。こういう時代がくると、技術の変化は、ほとんど自動的にマニュ 
アル作成作業に反映され、そこから得られるノウハウが、さらにチュートリアル•プログラム 
の作成に役立てられることになるだろう。 

書き、描き、出版するというテクノロジーのほとんどすべての進歩によって、原稿を書き換 
えるのに必要なコストや手間は、どんどん軽減されていく。ほんの数年前には、驚くほど高価 
で時間のかかった校正作業も、今では安価でしかも早くできる。したがって、数年後には、本 
書が提唱しているような守りに徹したややかたくるしい方法は、比較的大がかりな マニュアル 
にのみふさわしいものとなるだろう。ちょっとした マニュアルに ついては、それを作り、テス 
卜し、作りっぱなしにしたとしても、その費用はたいしたことはなくなり、モデルを作ってそ 
れをテストするまでもなくなるだろう。 

新しいテクノロジーは、徐々にマニュアルの質や使いやすさを高めるばかりでなく、その短 
期的コストや作成期間も削減してくれるだろう。事実、こうした傾向は、マニュアルの品質向 
上を妨げる2大要因を凌駕するものである。2つの要因とは、直接的な出費を近視眼的な利益で 
見ようとすることと、プロジェクトの期限をせっかちに先取りしようとすることである。言い 
換えれば、使いやすいマニュアルなら、必ず出費に見合う利益をもたらしてくれるものだが、 
第五世代においては、そうした原価償却期間は、劇的に短くなるだろう。 

要するに、情報処理テクノロジーの次世代は、われわれに書きたいように書き、描きたいよ 
うに描く能力を与えてくれるだろう。われわれは、こうした可能性に向けて着実に歩んで行く 
だろう。われわれはこの並外れたパワーを William Zinsser のいう「うまく書くための3大目 
標」*すなわち、明確さ、簡潔さ、そして人間らしさを追求するために利用したいと願うもので 
ある0 


原注* William Zinsser の「うまく書く ための3大目標 」： 「Writing With a Word Processor 」 
(New York : Harper Colophon Books ,) 1983， p .112 
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付録 


A . “構造化”マニュアル目次の実例 
巳.本書において使用される用語抜粋 
C . ドキュメンターのための参考文献 
□. ドキュメンターのためのソフトウェア • ツール 
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付録 


A . “構造化”マ ニ ュアル目次の実例 


以下の例は、本書に書かれているアウトライン作成の趣旨を実証したものである。（もちろん 
これらのアウトラインは、そのまま目次として使用される。） 


図表 A .1 ライン • エディ ター、通称ライン•ェドのオペレーター • ガイド 


1. 本マニュアルの読み方 

2. 2つの機能：人力と編集 

3. ライン•エド人力の仕方： LEDIT について 

4. ライン•エドコマンドの人力方法 
4.1 カーソル/ボインターの動かし方 
4.2 新規データを入力する （ input ) 

4.3 追加データを挿入する 

4.4 2つのデータを結合する 

4.5 既存のデータを呼び込む 

4.6 不要なデータを削除する 

4.7 データを移動させる 

4.8 ファイル内の“全体的”蛮更をする 

5. ライン•エドの出力管理 

5.1 人出力のフォーマットをする （3 つの方法） 
5.2 印刷プロトコルを指定する 

6. 削除した项目を再生する 
付録：メッセージー覽 


図表 A .2 ワープロ.システムの事務管理者用ガイド 


1. 文書処理部門の役割分担 

1.1 認可：誰が仕事を承認するか 
1.2 仕事の優先順位をどう決めるか 
1.3 組織体系一覧 
1.4 義務および職責一覧 

1.5 ワープロ機能使用のための8つの必須条件 

2. ワープロ装置の起動法 

2.1 メイン処理装置を動かす 
2.2 プリンターを動かす 
2.3 通信路を開く 

3. 第一段階処理：基本的な文書処理 
3.1 文書ファイルを定義する 

3.2 テキストを入力する 
3.3 校正用原稿を印刷する 
3.4 テキストを編集する 
3.4.1 第1稿でのもっとも一般的な20の誤り 
3.4.2 もっとも難しい3つの校正 
3.5 最終原稿を印刷する 
3.6 最終原稿を電子メールで送る 

4. 第二段階処理：複雑で#門的な文書 
4.1 旧文書群から文書を集める 

4.2 文書変数を結合する 

4.3 ワープロソフトで計算処理をする 

4.4 郵送/酉己布ファイルを作る 

4.5 曖味な入力を解釈する（デフォルト•ルール） 

5. 方針：全文書の収集と記憶 

6. 方針：クライアントの信賴を保持する 

7. 方針：著作者と管理者層の圧力に屈しない 
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図表 A .3 専用電話ネットワーク作成マニュアル(抜粋) 


第3章テリトリー•マップを構築し実証する 
3.1 各テリトリー•セットは電話データベースである 
3.2 新規テリトリー•セットの開始の仕方 
3.3 1 セクター のテリト リー •セットにデータを入力する 
3.4 AZ -60 から AZ -190 へセット•データを転送する 
3.5 補助データベース （ INTERIM ) を作成する方法 

3.6 INTERIM からテリトリー•セットへデータを読み込む 

3.7 グラフ•マップへのアクセスの仕方 
3.8 マップ全体に関する5つの必要条件 
3.9 システムにマップを“導入”する方法 
3.10マップ•データを効率よく入力する手順 
3.11 グラフ•マップの ZOOM 機能の使い方 
3.12 マップの操作方法 

1ビルとノードを追加する 
2ビルとノードを変更する 
3端末データを追加する 
4端末プロファイルを変更する 
5端末/設置場所のマトリックスを修正する 
6 2つのノー ド間にセグメントを追口する 

3.13 人カデータの確認の仕方 
3.14 点検：テリトリ ー•セットのチェックリスト 


図表 A.4 電子メール•システム （E-POST) のユーザー•ガイド 


1 . 本マニュアルで使用される規約 

2. 通常のメールの代わりに E-POST を使う 3 つのメリット 

3. E-POST メッセージをいつ受け取ったらよいか 

4. E-POST にアクセスする 

5. E-POST から ヘルプを 得る 

6. E-POST を利用する 

7. E-POST のインデックスを利用する 
7.1 インデックスにアクセスする 
7.2 姓に U のつく名前を検索する 

7.3 口座番号や暗証番号によって U のつく名前を検索する 
7.4 他の OGR コンピュータから U のつく名前を検索する 

8. 送信リストを利用する：監視 

8.1 送信リストをセットアップする 
8.2 送信リストを変更する 

8.3 送信リストで E-POST メッセージの送り先を決める 

9. E-POST メッセージを印刷する： 3 つの方法 
9.1 画面を印刷する 

9.2 STORE 機能を使って印刷する 

9.2.1 E-POST メッセージを STORE として保管する 

9.2.2 STORE ファイルを印刷する 
9.3 ワープロ機能を使って印刷する 

9.3.1 E-POST メッセージを文書として保管する 

9.3.2 SCRIBE-15 に文書を送る 

9.3.3 SCRIBE-15 の文書番号によってメッセージを印刷する 

10. 既存のファイルを E-POST メッセージとして送る方法 

11 . サブ•インデックスに E-POST メッセージをファイルする方法 

12. E-POST コマンドー觜 
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付録 


巳_本書におし A て使用される用語抜粋 


下記の表は、本書において使用されているいくつかの重要な用語を定義したものである。 


用語 定義 


アクセス容易性 
( accessibility ) 

エンジニアタイプ 

^engineer stereotype ) 

可読性 

^ readability ) 

可用性 

(availability) 

教育用モジュール 
vmstrucuonal module ) 
業務別 

( task - oriented ) 

芸術家タイプ 
(artistic stereotype ) 
構造化 
( structured ) 


構造化アウトライン 
(structured outline ) 

構造上の欠陥 
(structural error ) 

GOTO 

項目/対象者のマトリックス 
( topic/audience matrix ) 


信頼性 

( reliability ) 

ストーリーボード 

( storyboard ) 

対象読者 
( audience ) 

適合性 
( suitability ) 

丁'モンストレーシヨン.モジユ ーノレ 

(demonstration module ) 


マニュアルからの情報の入手、あるいは引出しが容易 
にできる様子 

草稿執筆にはあまり努力をせず、分析や設計にほとん 
どの力を傾けるような書き方 

処理の推移に沿って読み進むことのできる様子、難易 
度順に書かれることが多い 
マニュアルおよび必要情報の有無 

初心者を対象として、ある1つの操作方法や概念などを 

新たに解説するマニュアルの部分 

ユーザーの 携わる実務に即して考案されている〜 


分析や設計にはあまり力を入れず、原稿執筆にそのほ 
とんどの努力を費やすような書き方 
そのプロセスがトップダウン（下方展開型）分析やモ 
デルの作成によって考案された〜、その構造がいくつ 
かのモジュールとその組合わせになっている〜 

構造化されたマニュアル内の各モジュールに付けられ 
たへッドラインのリスト 

マニュアルの内容をもっとも読みやすい順番に構成す 
る上での誤り 

無条件分岐；マニュアルにおいては、流れの途中で他 
のモジュールに出入りすること 

マニュアルに書かれるべき項目と対象となるユーザー 
(読者）を縦横に配列した一覧表で、マニュアルの構成 
を考えるのに使用される 

正しい運用の妨げとなったり、ューザーに誤解を与え 
たりしない様子 

マニュアル内の各モジュールの仕様書や、取り上げら 
れているマニュアルのモデルを掲示する作業板 
共通の使用目的（類似した業務内容）と共通の経験を 
持つ読者層 

マニュアルがいかにユーザーの使用目的にマッチし、 
その業務をどこまで支援できるかという度合い 
熟練者を対象として、ある処理の全過程を解説するこ 
とを目的としたマニュアルの部分 
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動機付けモジュール 
(motivational module ) 

表現上の失策 
(tactical error ) 

ヘッドライン 

( headline ) 

方針上の失敗 
(strategic error ) 

マニュアルセット 

^documentation set ) 

メンテナンスのしやすさ 
vmaintamability ) 

モジュ ーノレ 

vmodule ) 

モデル 

vmodel ) 

ューザー 用文書 
〈user documentation ) 

有用性 

vusabnity ) 

有用性の指標 
'.usability index ) 

リファレンス，モジュー 

(reference module ) 
redundancy 


読者があまり実行したがらない事柄を実行させるよう 
仕向けるマニュアルの部分 

マニュアルの 草稿を、より 明白に、 より読みやすく編 
集する上での誤り 

ある テーマ あるいは実際的な表現が盛り込まれた表題 
で、マニュアルの各モジュールに付けられる 

マニュアルと情報製品を正しく分析し、再構築する上 
での誤り 

マニュアルおよび他の情報製品の全体を、対象となる 
システムに関連付けて定義した企画案 

(保守性） システムあるいはマニュアルをバグ取りしたり、修 

正•改良したりしやすい度合い 

システムあるいはマニュアルにおいて、ある1つの機能 
を果たす独立した最小単位 

システムあるいは製品のテストを容易にするために用 
いられる設計図 

ユーザーがある特定の技術を応用することを助けるよ 
う考案されたあらゆる文書（情報製品も含む） 

システムや製品、マニュアルの使いやすさ 

マニュアルの使いやすさの度合い。読者が読飛ばしや 
枝分かれ、回り道をする回数が多いほど、そのマニュ 
アルは読みにくいものとなる 

ル 予備の覚書きとして、後でユーザーが“参照する”の 

に役立つマニュアルの部分 

読者の負担を軽減し、混乱せずに集中できるよう配慮 
して、繰り返し解説すること 
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C - ドキユメンターのための參考文献 


マニュアル作成に関する研究は確かに新しい分野だが、今までにもまるっきりなかったわけ 
ではない。決して多くはないが、充分役に立つ書籍や定期刊行物のライブラリを次に挙げよう。 
これらは、駆出しのドキュメンターにとって（いや、ベテランにとっても）非常にためになる 
ものであろう0 


まず推薦図書をアルファべット順に紹介するが、その前に特に価値ある1冊を挙げておこう。 

Sandra Pakin & Associates . Documentation Development Methodology . 

Prentice - Hall , 1984. 

この極めて有益な著作は、駆出しのライターにうってつけの1冊である。また、文書作成に関 
して基準を持っていない会社は、この本の内容を基準や作成手順のマニュアル（手引書）とし 
て取り入れることもできるだろう。 

Pakin の著書に加えて、他にも以下のようなマニュアル作成に関する有用な文献がある。 


d ’ Agenais , J ” and J . Carruthers . Creating Effective Manuals . South-Western Publishing 
Company , 1984. 

Grimm , Susan . How to Write Computer Manuals for Users . Lifetime Learning , 1982. 
Horn , Robert . How to Write Information Mapping . Information Resources Inc , 1976. 
Kelly , Derek . Documenting Computer Application Systems . Petrocelli Books , 1983. 
Matthies , Leslie . The New Play script Procedure . Office Publications , 1977. 

Rubin , M . L . ( ed .). Documentation Standards and Procedures for On-Line Systems . Van 
Nostrand Reinhold , 1979. 

Schoff , G ., and P . Robinson . Writing & Designing Operator Manuals . Lifetime Learning , 
1984. 

Zaneski , Richard . Software Manual Production Simplified Petrocelli , 1982. 


マニュアル 作成に起用され た 人々の多くが、専門職としてのテクニカル • ライティングの分 
野では新参者である。以下の本は、特に技術的および科学的な主題を、いかに明快に書くかに 
関するもっとも定評ある著作の一部である。 


Brogan , John . Clear Technical Writing . McGraw - Hill , 1973. 

Michaelson , Herbert B . How to write and Publish Engineering Papers and Reports . ISI 
Press , 1982. 

O ’ Rourke , John . Writing for the Reader . Digital Equipment Corp . No . DECOO - XWRDA - 
A - D , 1976. 

Skees , William . Writing Handbook for Computer Professionals . Lifetime Learning , 1982. 
Strunk , W ., and E . B . White . The Elements of Style , 3 rd ed . Macmillan , 1979. 

Van Duyn , Julia . The DP Professional’s Guide to Writing Effective Technical Com ¬ 
munications . Wiley , 1982. 

Weiss , Edmond . The Writing System for Engineers and Scientists . Prentice - Hall , 1982. 

マニュアル 作成に携わる人々は、たいていの場合、その システム に関する他の文書（主に企 
画書、仕様書、報告書など）も書かされることが多い。下に挙げた書物は、コンピュータに関 
するプロジヱクトの管理 • 運営に必要な文書について語っている。 
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Harper, William. Data Processing Documentation , 2nd, ed. Prentice-Hall, 1980. 

London, K. Documentation Standards . 2nd ed. Mason & Lipscomb, 1974. 

Long, Larry. DP Documentation and Procedures Manual . Reston, 197b. 

National Bureau of Standards/Institute for Computer Sciences & rechnology 
Computer Model Documentation Guide (500-73) 

Proceed’s of the NBS Software Documentation Workshop (500-94) 

Guidelines for Documentation of Computer Programs and Automated Data Systems 
(FIPS PUB 38 ) 

Poschmann , A . Standards and Procedures for Systems Documentation . AMACOM, 1983. 
Sides, Charles H. How to Write Papers and Reports About Computer Technology . ISI Press, 
1984. 

さらに、データ処理やコンピュータ科学に関する経験のない人々は、 「Computerworld」 誌に 
毎週掲載される “In-Depth” のコーナーを読む習慣を持つことをお勧めする。 

製造業に携わるもっともクリエイティブな頭脳労働者たちが、彼らの最新のアイデアや書き 
かけの本の一部を、その コーナーで 紹介している。 

マニュアル作成に関する記事は、いたるところから (Sunday newspapers からも）飛び出て 
くる。しかし、以下の定期刊行物は、この主題について定期的に書いている。 

FOLIO , published by Pakin & Associates in Chicago 

*(The SIGDOC Newsletter ), published by the Special Interest Group on Documentation of 
the Association for Computing Machinery (ACM) in New York 
Technical Communication , the Journal of the Society for Technical Communication, 
Washington D.C. 

IEEE Transactions on Professional Communication 

“Simply Stated”，published by Document Design Center, Washington, D.C. 


おそらくもっとも読みやすい論文や記事の集成書は、年刊の 「Proceedings of the Interna¬ 
tional Technical Communications Conference」 だろう。この選集は Society for Technical 
Communications を通して手に入れることができるもので、テクニカル•コミュニケーション 
全般に関するもっとも刺激的で有益な本である。またマニュアル作成に限定して読んでもおも 
しろい。 
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D . ドキュメンターのためのソフトウェア•ツール 


マニュアルのライターは、自分の属する文書処理や情報処理の部門で仕事をするために直接 
必要となる技術や技能を、直ちに身に着けなければならない0これは、マニュアルの品質を向 
上させるだけではなく、ユーザーやシステムやマニュアルに関する問題を見抜く洞察力を彼ら 
に与えることにもなる。 


#言葉やテキストに関する製品 

• 本格ワープロ •パッケージ：テキスト全体の移動（カット•アンド•ぺースト）や書式 
設定（ページレイアウト）ができる。ワープロ •プログラムのもっとも進んだ機能は、 
フッティング、変則的なページ • ナンバリング、プリント.スプーリング（文書印刷中 
に他の文書を編集できる機能）などである。 

• タイプセッティング.インターフェイス：ワープロの文書ファイルを写植用の磁気命令 
変換する。こうすればテキストを再入力する必要がなくなる。 

•レタリング • プログラム： 表題や図表をプリントしたりプロットしたりする際、 用意 さ 
れているフォントを大きいサイズのキャラクタに変えることができる。（このプログラム 
は、プリンターに装着できるよう、 マイクロ* チップとして購入することもできる。） 

• アウトライン作成ツール：最近急成長を見せているプログラムの1つで、執筆者が自分の 
アイデアを練ったり、そのアイデアをさまざまな階層構造や順番に構成したりするのに 
役立つ。 

•テキスト管理機能：テキストをコード化し、データベース内に収納する。こうしておけ 
ば、ある特定の筋道の手順を再現したり、“モジュール”を引き出したりするだけでマニュ 
アルを“書く”ことができる。 

• いわゆる著作ツールあるいは 言語：コンピュータベースのトレーニング.プログラムや 
オンライン•チュートリアルを作成するのに役立つソフトウェア製品。 

• 編集支援プログラム：スペル•チェックはもとより、場合によっては文体や用法の問題 
をチェックしたり、読みやすさの点数を計算することもある。 

•グラフィックやアートに関する製品 

• ビジネス.チャート.パッケージ：統計データからちょっとした折れ線、棒、円グラフ 
などを作成するのに使用できる。 

•サイン•メーキング•パッケージ：おもに文字で構成されるタイトルぺージその他の提 
示物（スライドや透かし文字も含む）を作成するよう設計されたもの。 

• ダイヤグラム.ツール： フロー チャート、データ • フロー . ダイヤグラム、組織構造図、 
ガント•チャート、その他ビジネスやデータ処理の分野で頻繁に使用されるダイヤダラ 
ムを作成する。 

• ドローイング•アンド•ペインティング•プログラム： フリ ー ハンドの作図を可能にし、 
それを磁気媒体に保存したり、プリンターやプロッターに出力したりできる。これらの 
製品は、たいてい標準印字辞書を持っており、さまざまな形状で使用できる。 

• “クリップ•アート”ライブラリ：印字やイラストなどのライブラリで、ビジネス文書 
などにプリントあるいはプロットすることができる。たいていドローイング.アンド* 
ペインティング，プログラムの拡張機能として供給される。何百ものクリップ•アート 




付録 


191 


を搭載したディスクを購入することは、商業デザイナーに頼んで1〜2枚描いてもらうよ 
り安上がりなことが多い。 

• グラフィック強化プログラム：シンプルなビジネス•チャートやダイヤグラムを見ばえ 
のいいものにしたり、改良したりするプログラム。平面図を立体化することが多い。 

•ユーティリティおよび生産性向上に関する製品 

•プロジェクト.マネジメント.パッケージ：マニュアル作成の管理者が、マニュアルや 
他の情報製品の開発に必要なスケジュールを組んだり、予算をたてたりするのを助ける。 
モジュール化の方法でマニュアルを設計•作成するなら、プロジェクト•マネジメント 
システムのあらゆる機能を大いに活用することができる。つまりクリテイカルパスによ 
るスケジューリング、リソース（人員•資材）の均一配分（山崩し）、長期予測など。 

• キー 定義プログラム：ドキュメンターがキーボードのキー機能を変更できるようにす 
る。このプログラムは、キーボードのキーの再定義（標準キーボードをそっくり変える 
ことも）をすることができるが、もっと重要なことは、ごく少数のキーに50〜60の機能 
を持たせることができるということである。さらに“マクロ定義”（長い操作手順を2、 

3のキー操作でできるようにする機能）やよく出てくるフレーズ（繰り返し使用される名 
詞や用語）をコンピュータの辞書に登録したりすることもできる。これらのユーティリ 
ティ•プログラムは、延々と続く気の滅入るような労力を節約してくれる。 

• スプレッドシートおよびファイル管理プログラム：最後に、もっともポピュラーなビジ 
ネス•プログラムだか、これらはドキュメンターにとっても非常に有効である。スプレッ 
ドシートは、スケジューリングや財務計画に使用できるだけではなく、どんなマニュア 
ルが必要かを分析するための項目/対象者のマトリックスを作成するのにも役立つ。 
ファイル管理プログラム（あるいはデータベース管理システム）は、基本的に文書ファ 
イル、特にメンテナンスが必要となるものを保管するためのものである。さらに、ほと 
んどのファイル管理プログラムが、ストーリーボード作業のために、モジュール•スぺッ 
クを保存し、印刷し、操作するツールとしてプログラミングすることができる。 
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【数字.アルファベット】 

1ぺージモジュール 84 
2ページモジュール 82-83 
GOTO (なき） 19,30,130, 138-189 
Hughes Aircraft 53,82 
redundancy 
信頼性 34 
図表と本文100 
■ ノイズと エントロピー 34 
一の効果 132 
一の役割 132-133 
モジュール間の一 132-133 

【ぁ行】 

アウトライン 

階層構造 134-135 
構造化一 80-81,88-89 
従来型一 78-79,81,88-89 
変換 90-91 
アクセス容易性 19 
誤り 44,96 
ウィンドウ176 
エンジニアタイプ43 


オンライン 173-177 
ウィンドウ176 
—チュートリアル 111,175 
汎用型マニュアル 73 
マニュアルをなくす方法 175 

【か行】 

階層構造 134 
可読性 19 

一の指標 154-155 
—のために編集する 154-157 
可用性 18 
完全主義 22-23 
管理 

クリティカルパス 143 
コストか有用性か 22,34 
指数関数 45 
執筆者の一 140-143 
執筆の段階 142 
費用の一 11,62 
プランニング20 
プロジェクトチーム 64 
並行作業 47 

マニュアル セツ ト•メモ 74 
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見積り 

図表の一78 
モジュール化 53 
モジュールの数 92 
メンテナンスの一 161-169 
優先順位74 
予算44 

技術面の専門家64 
吸引力158 

業務別マニュアル 19,66 
近視眼的発想 22-23 
経済性34 
芸術家タイプ43 
コーデイネーター 64 
構造化 50-51 

ーアウトライン 
一の条件80 

へデイングからへ ッドラ インへ 88-89 
変換 90-91 
一設計 50-51 
—分析50 

構造上の欠陥 20-21,30-31 

項目/対象者のマトリックス70 

誤解 6-7 

コスト 34-3 5,96 

コスト 評定11 

コントロ ール 16 - 17 

【さ行】 

作業分解図 58-59 
参考文献 188-189 
障害22 
初稿 

言葉の使いすぎ148 

省略のしすぎ149 

単語や言い回しのバグ 148-149 


中心課題146 
一の執筆 137-143 
表現のバグ 150-151 
文章のバグ 150-151 
執筆者 

第一稿を書く139 
一の選択 • 管理 140-141 
執筆•編纂 

初稿を書く 138-143 
創造ではなく、実として139 
プロジェクト管理による一142 

指標 

有用性の一30 

ジャンプ.スキップ.ループ.ブランチ 

17，19,30,33，130，138-139 
情報処理システムとしての読者16 
神経質69 
信頼性 36-37 

スト ー リ ー ボ ー ド 

作業プラン54 
—の作成 128-129 
一の変更 130-131 
Hughes Aircraft 53 

図表 

同じ内容を繰り返す100 
一の種類 100-101 
本文の redundancy として100 
スペース 34-35 
性急さ 22-23 
設計 

構造化一50 
一の凍結129,138 
見越しの一164 


索引 
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【た行】 

第一原理28 
第一稿 

—の作成 137-143 
一のテスト 146-147 
対象(読)者 

—別マニュアル 72-73 
一を定義する68 
チュートリアル12 
チュートリアル.モジュール 110-115 
直列型 32-33 
手順 

説明不要となるまで修正175 
詰め込みすぎモジュール103 
マニュアル によってテストする 28,96 
テスト 

初稿の一 146-147 
ストーリー ボー ドに よる 128-131 
方針、構造、表現に関する21，31 
モデルに よる96 

データ •フロー • ダイヤグラム 55-57 
デバイス 10-11 
デモンストレーシヨン12 

デモンストレーシヨン.モジユール 116-120 

動機付け13 

動機付けモジュール 104-109 
凍結129 
土壌43,44 

トップダウン作業とテスト 44-4 5,50 

【な行】 

二 ーズ 

項目/対象者のマトリックス70 
誤解 6-7 
分化72 
分析 61-75 


【は行】 

費用 44-45 
評価基準 

システムの 一 26 

表現上の失策20-21， 30-31 
フォグ指数 154-157 
プログラマー42 
プログラミング44 
プロジェクトチーム 64 
プロの手による編集19 
分解50 

文章のバグ 150-151 
分析 

機能と項目の一 66-67 
境界部分と重複部分72 
構造化一50 

項目/対象者のマトリックス70 
どんなマニュアルが求められているか 

61-75 

プ ロジェ クト チームを 組織す る 64 
ページごとの設計81,82 
並列型 32-33 
へッドライン 

対象者別の一89 
へデイングとの対比80,86 -89 
モジュールの一 86-87 

編集 

5つのカテゴリー147 
作業分解図58 

指示文を曖昧にする10項目 152-153 
初稿をテストする 146-147 
単語や言い回しのバグ 148-149 
読者の気をそらす原因 158-159 
読みやすさのために 154-157 
方針上の失敗 20-21,30-31 
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【ま行】 

マニュアル 

安全性の確保73 
インデックス73 

GOTO なき17，19,30,33，130，138 

誤解6 

コスト評定11 

システム開発28,96 

将来 174-181 

図表 100-101 

成功と失敗 15-23 

第一原理 28-29 

直列型と並列型 32-33 

定養4 

テスト146 

デバイスとしての 10-11 

なぜかうまく書かれないか8 

汎用型と対象者別 72-73 

プログラミングとの類似性 xii ,42,44 

ヘルプ画面 5 

メンテナンス 162-169 

モデルとしての 28,97 

役割 12-13 

マニュアル作成 

システムとしての 25-37 
第五世代の一180 
一の基準 18-1 9,46 
—の3つの誤り 20-21 
プログラミングとの類似性44 
文学との比較6 
マニュアルセット 62-63 
マニュアルセット•メモ 64-65,74-75 
マニュアル 不要のシステム 174-175 
メンテナンス 

技術的な変更162 
刺激と反応 162-163 


古いマニュアルをモジュール化する 168 
見越しの設計で改善する164,169 

目次 

—としてのアウトライン78 
連続型と階層型 134-135 

モジユ ーノレ 

-化52,82 

—間の redundancy 132-133 

—サイズ52,80-85,92 

ースペック 98-99 

チュートリアルー 110-121 

詰め込みすぎ一 102-103 

等価一165 

動機付け一 104-109 

2 ページー 82-85 

一の階層化134 

一の数 92-93 

一の凝集度53 

一の登録薄 164-165 

一のへ ッ ドライン 86-87, 90-91 

デモンストレーションー 116-121 

リファレンスー 122-127 

モデル 

—としてのマニュアル 96 
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現代はまさに「マニュアル化社会」である。コンピュータ•テクノロジーの発達により、マ 
ニュアルは専門技術文書から、予備知識のないエンド•ユーザーが手にする文献となった〇し 
かし今までは、マニュアル作成を“エンジニアリング”としてとらえ、明確な方法論を提示し 
てくれる「教科書」はないに等しかった。本書はテクニカルライターをはじめ、技術文書の作 
成に携わるあらゆる人々に確かな指針を与えてくれる“福音書”である。本書はコンピュータ • 
プログラミングの方法論である「構造化分析」「構造化設計」をドキュメント作成に応用したも 
のである。さらに、テクノロジー開発の次世代において、マニュアル作成がいかにコンピュー 
夕化されていくかを“見越し”た優れた「序説」でもある。 


鲁本書はテクニカルライターの“福音書”である 

本書は Edmond H . Weiss の “How to Write a Usable User Manual ” (ISI Press , 1985) 
の全訳である。「使いやすいューザー•マニュアルの書き方」とでも訳すべきだろうが、著者も 
序文で語っている通り、テクニカルライターのみならず、マニュアルをはじめとするあらゆる 
技術文書の作成に関わる人々全員に捧げられた“福音書”であるという思いを込め、あえて「マ 
ニュアル•バイブル」という大胆な邦題を付した。その名に恥じぬ内容であると確信している。 
事実わが社ではすでに2年前から本書の方法論にのっとって、パソコン用ソフトウェアのマ 
ニュアルをはじめとするさまざまなューザー用文書の作成を手掛け、単なる机上の空論ではな 
い本書の実践面での有効性を立証し、クライアントやエンド•ューザーから高い評価を得てい 
る。さらにわが社では本書の方法論をもとに、パソコン用データベース言語を用いて“マニュ 
アル•プランニング•ツール”を開発し、実務に応用している（ツールについては後で述べる）〇 

われわれのようにマニュアルやその他のューザー用文書の作成を任とする者らにとって、か 
つてこれほど骨太な、学問的体系にのっとった、しかも確かな指針を与えてくれる極めて実践 
的な「教科書」があっただろうか。いわゆるマニュアル作成に関する手引書の類はあるにはあっ 
たが、しょせん“つづりかた”の域を出ない枝葉末節の部分を扱ったものばかりで、手本とな 
るような優れた先達の業績があるわけでもなかった。少なくとも私にとっては、乏しいセンス 
とあてにならない勘にたよる試行錯誤の連続だったというのが正直な感想である。したがって 
本書の存在を知り、それを翻訳出版するという幸運に恵まれたことは、私にとって目からウロ 
コの落ちるような体験であり、文字通り本書は“救済の書”となってくれたわけである。事実 
この本一冊で、わが社の文書作成業務はすっかり塗り変えられてしまった。 

•「マニュアル化社会」がやってきた！ 

世はまさに「マニュアル化社会」である。恋愛の仕方から葬式の出し方まで、あらゆるもの 
が“マニュアル化”されている。日常生活のみならず、企業などの組織的な営利活動において 
も 、 CI (コーポレート •アイデンティティ） ブームともあいまって、 マニュアルが 単なる商品 
の付随物ではなく、市場競争に勝ち残る重要な鍵になるという認識が高まっている。しかしこ 
うしたマニュアルの重要性に関する認識は、何も今に始まったことではなく、われわれの先祖 
がまだチョンマゲを結っていた時代から、マニュアルは 「虎の巻」 とか「指南書」という形で 
庶民の生活に深く根付いていただけでなく、“天下取り”のための情報源としても重要な役割を 
演じてきたのである。 

しかし「虎の巻」とか「指南書」というもはや死語になりつつある言葉が“マニュアル”と 
いう言葉に姿を変えて現代によみがえったのには、やはり何といってもコンピュータ•テクノ 
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ロジーの発展が大きく関与しているといえるだろう。コンピュータという怪物の出現によって 
火の点いた技術革新は、今や日の出の勢いで日進月歩し、それにともなうシステムの複雑化、 
プロジ I クトの大規模化によって、時代はごく小数の天才的なプログラマーが密室の中でブロ 
イラーのようにこつこつと金の卵を生み出し続けていればよかった第一期から、複数の人間の 
組織的かっ有機的な共同作業が要求される第二期に突入している。こうした共同作業を可能と 
するためには、天才的なひらめきや勘にたよるやり方ではなく、万人に理解し得る体系的で普 
遍的な基準•ルール•指針というものが必要であり、複数の人間が同時に動く以上、スケジュー 
ルやコストを管理するプロジヱクト • マネジメントの手法とも結び付かなければならない。 

こうした状勢の変化から、 マニュアルの 作り方もおのずと変わってきたといえる。専門職で 
あるプロダラ マー や オペレーター が理解できればよかった マニュア ルが、今ではテクノロジー 
の開発とは無縁な家庭の主婦や子供達までが手にする文献となったのである。しかし実際の作 
成過程はどうか？ “ マニュアル （ manual ) ”という言葉はもともと 「 手造りの、手作業の」とい 
う形容詞であり、最近では“オートマチック”っまり「自動の、自動的な」という言葉の反意 
語として使われるケースが多いが、その語義通り、 マニュアル 作成の現場は相変わらず“手作 
業の”域を出ないのが実状である。それは、今まで マニュアル 作成の機械化を可能にしてくれ 
る明確な方法論がなかったからにほかならず、おそらくは本書の出来を待たなければ実現でき 
得なかったことだろう。 

•日本はこの分野で10年遅れている 

ところで本書の画期的な点とは何だろう。「技術者にマニュアルを書かせるな」という今まで 
のタブーを破り、技術者に原稿を書かせる利点を積極的に主張した点だろうか？それも然り。 
マニュアル作成にブロジヱクト•マネジメントの手法を導入し、初稿執筆前のコスト算出と複 
数の執筆者の分担作業を可能にした点だろうか？それも然り。まったく畑違いの映画製作の手 
法である“ストーリーボード”を取り入れ、狭い専門分野にとどまらないすそ野の広がりをみ 
せた点だろうか？それも然り。しかし何といっても第一に挙げなければならないのは、コン 
ピュータ•プログラミングの方法論である「構造化分析」「構造化設計」を果敢にドキュメント 
作成に応用した点である。今やプログラム開発の主流となっているこの2っの方法論は、すで 
に10年以上も前にアメリカで確立されたものであるが、わが国ではようやく数年前からその手 
の文献や開発ツールが注目され出した。本書が世に出たのが2年前であるから、“構造化”の本 
家であるアメリカでさえ、その手法をドキュメンテーシヨンの分野に応用するのに10年の時が 
必要だった。しかし考えてみれば構造化の手法で開発されたシステムやソフトウェア製品に添 
付されるマニュアルが、構造化の手法で書かれるというのはあたりまえの話であり、むしろわ 
れわれは方法論の応用に10年もかかってしまったという事情の方に、文書作成に関する認識の 
低さをみるべきだろう。しかしこうした優れた先達の業績が世に出た以上、もはやわれわれは 
足踏みしているわけにはいかない。ここであらためてわれわれの共通の認識として、次のよう 
な大前提を掲げておこう： 

「マニュアル作成とは“文学”でも、単なる“つづりかた”でもなく、厳密な基準にのっとって 
行なわれる“ エンジニアリング” の一分野である。」 

•マニュアル作成は90%機械化できる！ 

本書において特筆すべきもう1つの点は、著者自身、テクノロジー開発の次世代において、 
マニュアル作成がいかにコンピュータ化されていくかを“見越し”て、いわば マニュアル 作成 
のコンピュータ化に向けての「序説」として本書を書いている点である。マニュアル作成はど 
の程度コンピュータ化できるだろうか？技術的には90%以上の機械化が可能であると考えられ 
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る。しかし「マニュアル作成は“エンジニアリング”である」と謳った以上、特に厳密にシス 
テム化しなければならないのは、分析•設計のプロセスである。今まで一番コンピュータ化が 
望まれていながら、それを可能とする明確な方法論がなかったために後手に回っていたのがこ 
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すでにわが社では本書の方法論にもとづき“ マニュアル•プランニング•ツール”を 開発し、 
マニュアル 作成 をパソコン で データベース管理 していると冒頭で述べた が、 最後にこの ツール 
について少し紹介しておこう。 

まずこのツールで特徴的なことは、マニュアル作成の対象となる製品の仕様書をワープロま 
たはデータベースで管理する点である。本書にもあるように、製品の設計がしっかりしていて 
仕様書が完備されていれば、当然マニュアルも書きやすく、品質も向上し、手間も合理化され 
る。このツールでは仕様書の内容を項目ごとにコード番号を付けてマスター登録し、マニュア 
ルのどのモジュールに該当するかを指定しておけば、モジュール•スペックを書く際、自動的 
に仕様書の該当項目をモジュール内に読み込むことができる。 

この ツールは 上記の仕様書 マスター の他に、 プロ ジヱ クト 管理 データを 登録して おく「プロ 
ジェクトマスター」、マニュアルに 含めるべき項目の分析結果を登録して おく 「項目 マスター」、 
対象者分析の結果を登録して おく 「ユーザーマスター」、モジュール•スペックの 内容を収めた 
「モジュールマスター」などのマスターファイルから 構成されている。 これらのファイルが 有機 
的な関係で結合され、「項目 リスト」、 「対象者 リスト」、 「項目/対象者の マトリックス」、 そし 
て分析の プロセス 全体の報告書である 「マニュアルセット•メモ」 を自動的に出力する ことが 
できる。 

これらの分析結果をもとに、本書の示す設計の手順にそって、まず項目リストを従来型のア 
ウトラインに並べ換え、ヘディングの“文体”をヘッドラインの形に書き換えて独立アウトラ 
インを作り、それをさらに モジュール •サイズに分解して構造化アウトラインを作成する。こ 
うして項目リストは モジュール リストにコンバート（変換）されたことになる。 

モジュールにはすでにへ ッドラインが付けられているので、要約と図表の説明を書いて打ち 
出せば、 モジュール •スペックが出来上がる。前述したように製品の仕様書からその モジュー 
ルの内容に該当する項目を読み込むことができるので、それをそのまま注釈としてスペックに 
打ち出すこともできる。 

ストーリーボード作業を終了したら、その結果をモジュールリストに反映させ、設計を「凍 
結」させる。また、アウトラインが確定した時点で各モジュールに階層を表わす番号を付けれ 
ば、マニュアルの「目次」および版下製作や印刷の際に必要となる「台割」をページ番号付き 
で自動的に打ち出すこともできる。 

以上のように、マニュアル作成システムの基本的な骨組はすでに出来上がっているため、こ 
れをもとに、わが社ではさらに総合的なシステム開発に取り組んでいる。技術的には不可能な 
ものではないため、そう遠くない将来、マニュアル作成の90%システム化を実現できるだろう。 

本書は、実に多くの人々の協力によって翻訳出版にこぎつけたものである。特に社長みずか 
ら陣頭指揮に立って翻訳協力にあたってくださったフランス語情報センターの中平信也氏、 
まったくの無報酬で骨惜しみせぬ協力をくださり、さらにプロの翻訳家としての目を拙訳に注 
いでくださった浅岡伴夫氏、スケジュールの遅れに辛抱強く付き合ってくださった啓学出版の 
鈴木信行氏および高橋弘子女史に心から謝意を表したい。また、縁の下の力持ちとなってくだ 
さった立花芳子女史、岡部保之氏、中川和夫氏、山下寛氏、上野一成氏、戸辺雄一郎氏、染野 
芳輝氏、秦玄一氏にも末筆ながら深く感謝の意を表し、長すぎるあとがきの筆を置きたいと思 
1 〇 
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